From fda2137f1a1c2d092ca755de7b3bb7595d935498 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9mi=20Verschelde?= Date: Mon, 18 Jun 2018 09:13:49 +0200 Subject: [PATCH] Sync Weblate translations with Weblate template --- weblate/ar.po | 5031 +++++++++++---------------- weblate/ca.po | 5032 +++++++++++---------------- weblate/cs.po | 5032 +++++++++++---------------- weblate/da.po | 5032 +++++++++++---------------- weblate/de.po | 5038 +++++++++++---------------- weblate/el.po | 5033 +++++++++++---------------- weblate/es.po | 8272 +++++++++++++++++++++++--------------------- weblate/es_MX.po | 5031 +++++++++++---------------- weblate/fa.po | 5032 +++++++++++---------------- weblate/fi.po | 5034 +++++++++++---------------- weblate/fil.po | 5031 +++++++++++---------------- weblate/fr.po | 5061 +++++++++++---------------- weblate/he.po | 5032 +++++++++++---------------- weblate/hu.po | 5032 +++++++++++---------------- weblate/id.po | 5031 +++++++++++---------------- weblate/it.po | 5034 +++++++++++---------------- weblate/ja.po | 5031 +++++++++++---------------- weblate/ko.po | 5036 +++++++++++---------------- weblate/lt.po | 5031 +++++++++++---------------- weblate/ms.po | 5031 +++++++++++---------------- weblate/nb.po | 5031 +++++++++++---------------- weblate/nl.po | 5031 +++++++++++---------------- weblate/pl.po | 5009 +++++++++++---------------- weblate/pt_BR.po | 5062 +++++++++++---------------- weblate/pt_PT.po | 5032 +++++++++++---------------- weblate/ro.po | 5031 +++++++++++---------------- weblate/ru.po | 5042 +++++++++++---------------- weblate/sk.po | 5031 +++++++++++---------------- weblate/sl.po | 5032 +++++++++++---------------- weblate/sr_Latn.po | 5032 +++++++++++---------------- weblate/sv.po | 5032 +++++++++++---------------- weblate/th.po | 5032 +++++++++++---------------- weblate/tr.po | 5033 +++++++++++---------------- weblate/uk.po | 5051 +++++++++++---------------- weblate/vi.po | 5031 +++++++++++---------------- weblate/zh_CN.po | 5122 +++++++++++---------------- weblate/zh_TW.po | 5032 +++++++++++---------------- 37 files changed, 74834 insertions(+), 114749 deletions(-) diff --git a/weblate/ar.po b/weblate/ar.po index 99316f27e9..e7fc3d2b79 100644 --- a/weblate/ar.po +++ b/weblate/ar.po @@ -10,7 +10,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-05-27 17:34+0000\n" "Last-Translator: Rached Noureddine \n" "Language-Team: Arabic ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3286,109 +3288,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3396,55 +3398,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3452,57 +3454,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3512,17 +3514,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3530,7 +3532,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3538,55 +3540,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "جسيمات" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3594,24 +3596,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6355,7 +6357,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6378,7 +6380,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6389,8 +6391,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6412,7 +6414,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6476,27 +6478,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6504,17 +6506,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6524,54 +6526,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6580,7 +6582,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6589,18 +6591,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6608,7 +6610,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6616,14 +6618,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6633,60 +6635,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6696,11 +6698,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6708,7 +6710,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6716,15 +6718,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6733,38 +6735,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6773,20 +6775,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6794,15 +6796,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6951,7 +6953,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -6991,7 +6993,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7035,7 +7037,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7059,7 +7061,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7095,7 +7097,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7115,14 +7117,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7132,11 +7134,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7144,7 +7146,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7158,7 +7160,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7173,7 +7175,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7297,7 +7299,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7339,8 +7341,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7374,7 +7376,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7400,19 +7402,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7437,7 +7439,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7460,7 +7462,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7478,7 +7480,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7495,8 +7497,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7531,7 +7533,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7702,7 +7704,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7712,25 +7714,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7751,183 +7753,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7935,17 +7937,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7953,139 +7955,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8095,7 +8097,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8105,69 +8107,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8175,125 +8177,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8301,7 +8303,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8325,7 +8327,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8362,79 +8364,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8442,36 +8444,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11719,10 +11721,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12773,7 +12775,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13418,6 +13420,256 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14319,136 +14571,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14456,113 +14722,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14571,15 +14837,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14587,34 +14853,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14622,15 +14888,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14638,51 +14904,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14690,102 +14956,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14793,44 +15059,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16739,7 +17005,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16764,8 +17030,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16800,7 +17066,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16845,16 +17111,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16950,7 +17216,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17079,7 +17345,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17219,7 +17485,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17234,7 +17500,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17334,44 +17600,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17380,17 +17646,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17402,7 +17668,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17414,25 +17680,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17440,61 +17706,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17505,29 +17771,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17644,9 +17910,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17655,8 +17921,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17895,8 +18161,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18155,7 +18421,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18203,7 +18469,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18341,7 +18607,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18374,10 +18640,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18810,16 +19072,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18862,6 +19124,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19185,8 +19448,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19200,14 +19463,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19239,67 +19502,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19308,334 +19571,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19643,11 +19906,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19656,30 +19919,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19687,11 +19950,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19701,11 +19964,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19714,66 +19977,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19781,38 +20044,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19823,13 +20086,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19872,8 +20135,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19884,7 +20147,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19912,56 +20175,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19969,26 +20232,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -19996,23 +20259,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20021,129 +20284,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20151,111 +20413,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20285,61 +20547,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20347,7 +20610,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20355,42 +20618,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20398,31 +20661,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20437,186 +20700,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20630,38 +20893,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20670,44 +20933,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20715,27 +20978,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20743,7 +21006,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20751,13 +21014,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20766,113 +21029,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20880,110 +21143,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -20991,12 +21254,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21009,213 +21272,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21223,38 +21486,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21264,149 +21527,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21414,143 +21677,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21558,78 +21822,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21670,10 +21934,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21725,11 +21989,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21765,7 +22029,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21776,8 +22040,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21792,23 +22056,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21819,7 +22084,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22033,9 +22298,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22043,46 +22308,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22090,92 +22356,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22197,28 +22462,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22227,7 +22491,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22238,7 +22502,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22248,50 +22512,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22299,137 +22563,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22437,31 +22710,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22475,45 +22748,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22521,68 +22799,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22590,14 +22868,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22610,8 +22888,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22655,7 +22933,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30134,14 +30412,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30161,40 +30439,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30202,37 +30484,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30240,7 +30522,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30250,79 +30532,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30330,7 +30610,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30342,39 +30622,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30383,11 +30663,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30395,51 +30675,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30447,55 +30727,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30504,11 +30784,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30788,10 +31068,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32650,1532 +32926,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40167,7 +38917,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40555,226 +39305,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47220,9 +46089,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47276,7 +46145,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51872,6 +50741,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/ca.po b/weblate/ca.po index e6f7ed3ea5..5c9d1af697 100644 --- a/weblate/ca.po +++ b/weblate/ca.po @@ -9,7 +9,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-09 04:35+0000\n" "Last-Translator: Roger Blanco Ribera \n" "Language-Team: Catalan ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3406,109 +3408,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3516,55 +3518,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3572,57 +3574,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3632,17 +3634,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3650,7 +3652,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3658,55 +3660,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3714,24 +3716,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6475,7 +6477,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6498,7 +6500,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6509,8 +6511,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6532,7 +6534,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6596,27 +6598,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6624,17 +6626,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6644,54 +6646,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6700,7 +6702,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6709,18 +6711,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6728,7 +6730,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6736,14 +6738,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6753,60 +6755,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6816,11 +6818,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6828,7 +6830,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6836,15 +6838,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6853,38 +6855,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6893,20 +6895,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6914,15 +6916,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7071,7 +7073,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7111,7 +7113,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7155,7 +7157,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7179,7 +7181,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7215,7 +7217,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7235,14 +7237,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7252,11 +7254,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7264,7 +7266,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7278,7 +7280,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7293,7 +7295,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7417,7 +7419,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7459,8 +7461,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7494,7 +7496,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7520,19 +7522,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7557,7 +7559,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7580,7 +7582,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7598,7 +7600,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7615,8 +7617,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7651,7 +7653,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7822,7 +7824,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7832,25 +7834,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7871,184 +7873,184 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 #, fuzzy msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "X11 (Linux, \\*BSD)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8056,17 +8058,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8074,139 +8076,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8216,7 +8218,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8226,69 +8228,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8296,125 +8298,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8422,7 +8424,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8446,7 +8448,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8483,79 +8485,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8563,36 +8565,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11840,10 +11842,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12894,7 +12896,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13539,6 +13541,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "No hi ha cap mena de restricció en l'ús del motor Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14440,136 +14693,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14577,113 +14844,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14692,15 +14959,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14708,34 +14975,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14743,15 +15010,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14759,51 +15026,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14811,102 +15078,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14914,44 +15181,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16860,7 +17127,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16885,8 +17152,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16921,7 +17188,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16966,16 +17233,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17071,7 +17338,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17200,7 +17467,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17340,7 +17607,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17355,7 +17622,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17455,44 +17722,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17501,17 +17768,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17523,7 +17790,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17535,25 +17802,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17561,61 +17828,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17626,29 +17893,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17765,9 +18032,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17776,8 +18043,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -18016,8 +18283,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18276,7 +18543,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18324,7 +18591,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18462,7 +18729,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18495,10 +18762,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18931,16 +19194,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18983,6 +19246,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19306,8 +19570,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19321,14 +19585,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19360,67 +19624,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19429,334 +19693,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19764,11 +20028,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19777,30 +20041,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19808,11 +20072,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19822,11 +20086,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19835,66 +20099,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19902,38 +20166,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19944,13 +20208,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19993,8 +20257,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -20005,7 +20269,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -20033,56 +20297,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20090,26 +20354,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20117,23 +20381,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20142,129 +20406,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20272,111 +20535,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20406,61 +20669,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20468,7 +20732,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20476,42 +20740,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20519,31 +20783,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20558,186 +20822,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20751,38 +21015,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20791,44 +21055,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20836,27 +21100,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20864,7 +21128,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20872,13 +21136,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20887,113 +21151,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -21001,110 +21265,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21112,12 +21376,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21130,213 +21394,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21344,38 +21608,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21385,149 +21649,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21535,143 +21799,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21679,78 +21944,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21791,10 +22056,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21846,11 +22111,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21886,7 +22151,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21897,8 +22162,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21913,23 +22178,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21940,7 +22206,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22154,9 +22420,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22164,46 +22430,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22211,92 +22478,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22318,28 +22584,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22348,7 +22613,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22359,7 +22624,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22369,50 +22634,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22420,137 +22685,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22558,31 +22832,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22596,45 +22870,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22642,68 +22921,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22711,14 +22990,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22731,8 +23010,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22776,7 +23055,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30255,14 +30534,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30282,40 +30561,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30323,37 +30606,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30361,7 +30644,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30371,79 +30654,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30451,7 +30732,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30463,39 +30744,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30504,11 +30785,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30516,51 +30797,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30568,55 +30849,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30625,11 +30906,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30909,10 +31190,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32771,1532 +33048,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40288,7 +39039,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40676,226 +39427,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47341,9 +46211,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47397,7 +46267,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51993,6 +50863,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/cs.po b/weblate/cs.po index df2cf71426..905a3c05ef 100644 --- a/weblate/cs.po +++ b/weblate/cs.po @@ -9,7 +9,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-05-20 16:35+0000\n" "Last-Translator: Josef Kuchař \n" "Language-Team: Czech ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3251,109 +3253,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3361,55 +3363,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3417,57 +3419,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3477,17 +3479,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3495,7 +3497,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3503,55 +3505,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3559,24 +3561,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6321,7 +6323,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6344,7 +6346,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6355,8 +6357,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6378,7 +6380,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6442,27 +6444,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6470,17 +6472,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6490,54 +6492,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6546,7 +6548,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6555,18 +6557,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6574,7 +6576,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6582,14 +6584,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6599,60 +6601,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6662,11 +6664,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6674,7 +6676,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6682,15 +6684,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6699,38 +6701,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6739,20 +6741,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6760,15 +6762,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6917,7 +6919,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -6957,7 +6959,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7001,7 +7003,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7025,7 +7027,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7061,7 +7063,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7081,14 +7083,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7098,11 +7100,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7110,7 +7112,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7124,7 +7126,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7139,7 +7141,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7263,7 +7265,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7305,8 +7307,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7340,7 +7342,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7366,19 +7368,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7403,7 +7405,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7426,7 +7428,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7444,7 +7446,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7461,8 +7463,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7497,7 +7499,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7668,7 +7670,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7678,25 +7680,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7717,183 +7719,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Licence" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7901,17 +7903,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7919,139 +7921,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8061,7 +8063,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8071,69 +8073,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8141,125 +8143,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8267,7 +8269,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8291,7 +8293,7 @@ msgstr "Cesta" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8328,79 +8330,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8408,36 +8410,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11685,10 +11687,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12740,7 +12742,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13385,6 +13387,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "Typ" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14286,136 +14539,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14423,113 +14690,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14538,15 +14805,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14554,34 +14821,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14589,15 +14856,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "FPS" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14605,51 +14872,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14657,102 +14924,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14760,44 +15027,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16706,7 +16973,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16731,8 +16998,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16767,7 +17034,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16812,16 +17079,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16917,7 +17184,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17046,7 +17313,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17186,7 +17453,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17201,7 +17468,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17301,44 +17568,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17347,17 +17614,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17369,7 +17636,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17381,25 +17648,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17407,61 +17674,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17472,29 +17739,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Nástroje" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17611,9 +17878,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17622,8 +17889,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17862,8 +18129,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18122,7 +18389,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18170,7 +18437,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18308,7 +18575,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18341,10 +18608,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18777,16 +19040,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18829,6 +19092,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19152,8 +19416,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19167,14 +19431,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19206,67 +19470,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19275,334 +19539,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19610,11 +19874,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19623,30 +19887,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19654,11 +19918,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19668,11 +19932,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Hloubka" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19681,66 +19945,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19748,38 +20012,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19790,13 +20054,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19839,8 +20103,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19851,7 +20115,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19879,56 +20143,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19936,26 +20200,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -19963,23 +20227,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -19988,129 +20252,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20118,111 +20381,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20252,61 +20515,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20314,7 +20578,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20322,42 +20586,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20365,31 +20629,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20404,186 +20668,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20597,38 +20861,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20637,44 +20901,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20682,27 +20946,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20710,7 +20974,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20718,13 +20982,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20733,113 +20997,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20847,110 +21111,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -20958,12 +21222,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -20976,213 +21240,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21190,38 +21454,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21231,149 +21495,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21381,143 +21645,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21525,78 +21790,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21637,10 +21902,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21692,11 +21957,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21732,7 +21997,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21743,8 +22008,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21759,23 +22024,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21786,7 +22052,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22000,9 +22266,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22010,46 +22276,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22057,92 +22324,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22164,28 +22430,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22194,7 +22459,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22205,7 +22470,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22215,50 +22480,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22266,137 +22531,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22404,31 +22678,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22442,45 +22716,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22488,68 +22767,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22557,14 +22836,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22577,8 +22856,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22622,7 +22901,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30101,14 +30380,14 @@ msgid "Audio" msgstr "Zvuk" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30128,40 +30407,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30169,37 +30452,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30207,7 +30490,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30217,79 +30500,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30297,7 +30578,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30309,39 +30590,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30350,11 +30631,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30362,51 +30643,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30414,55 +30695,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30471,11 +30752,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30755,10 +31036,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32617,1532 +32894,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40134,7 +38885,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40522,226 +39273,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47187,9 +46057,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47243,7 +46113,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51840,6 +50710,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/da.po b/weblate/da.po index 9b2a1ff182..50cfcd2624 100644 --- a/weblate/da.po +++ b/weblate/da.po @@ -9,7 +9,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-04-29 15:59+0000\n" "Last-Translator: Christoffer Schindel \n" "Language-Team: Danish ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3385,109 +3387,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3495,55 +3497,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3551,57 +3553,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3611,17 +3613,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3629,7 +3631,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3637,55 +3639,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3693,24 +3695,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6454,7 +6456,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6477,7 +6479,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6488,8 +6490,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6511,7 +6513,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6575,27 +6577,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6603,17 +6605,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6623,54 +6625,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6679,7 +6681,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6688,18 +6690,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6707,7 +6709,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6715,14 +6717,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6732,60 +6734,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6795,11 +6797,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6807,7 +6809,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6815,15 +6817,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6832,38 +6834,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6872,20 +6874,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6893,15 +6895,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7050,7 +7052,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7090,7 +7092,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7134,7 +7136,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7158,7 +7160,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7194,7 +7196,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7214,14 +7216,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7231,11 +7233,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7243,7 +7245,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7257,7 +7259,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7272,7 +7274,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7396,7 +7398,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7438,8 +7440,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7473,7 +7475,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7499,19 +7501,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7536,7 +7538,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7559,7 +7561,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7577,7 +7579,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7594,8 +7596,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7630,7 +7632,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7801,7 +7803,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7811,25 +7813,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7850,184 +7852,184 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 #, fuzzy msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "X11 (Linux, \\*BSD)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8035,17 +8037,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8053,139 +8055,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8195,7 +8197,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8205,69 +8207,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8275,125 +8277,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8401,7 +8403,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8425,7 +8427,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8462,79 +8464,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8542,36 +8544,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11819,10 +11821,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12873,7 +12875,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13518,6 +13520,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Der er ingen brugsrestriktioner på Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14419,136 +14672,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14556,113 +14823,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14671,15 +14938,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14687,34 +14954,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14722,15 +14989,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14738,51 +15005,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14790,102 +15057,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14893,44 +15160,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16839,7 +17106,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16864,8 +17131,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16900,7 +17167,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16945,16 +17212,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17050,7 +17317,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17179,7 +17446,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17319,7 +17586,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17334,7 +17601,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17434,44 +17701,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17480,17 +17747,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17502,7 +17769,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17514,25 +17781,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17540,61 +17807,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17605,29 +17872,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17744,9 +18011,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17755,8 +18022,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17995,8 +18262,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18255,7 +18522,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18303,7 +18570,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18441,7 +18708,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18474,10 +18741,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18910,16 +19173,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18962,6 +19225,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19285,8 +19549,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19300,14 +19564,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19339,67 +19603,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19408,334 +19672,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19743,11 +20007,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19756,30 +20020,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19787,11 +20051,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19801,11 +20065,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19814,66 +20078,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19881,38 +20145,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19923,13 +20187,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19972,8 +20236,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19984,7 +20248,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -20012,56 +20276,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20069,26 +20333,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20096,23 +20360,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20121,129 +20385,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20251,111 +20514,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20385,61 +20648,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20447,7 +20711,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20455,42 +20719,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20498,31 +20762,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20537,186 +20801,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20730,38 +20994,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20770,44 +21034,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20815,27 +21079,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20843,7 +21107,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20851,13 +21115,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20866,113 +21130,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20980,110 +21244,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21091,12 +21355,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21109,213 +21373,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21323,38 +21587,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21364,149 +21628,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21514,143 +21778,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21658,78 +21923,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21770,10 +22035,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21825,11 +22090,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21865,7 +22130,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21876,8 +22141,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21892,23 +22157,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21919,7 +22185,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22133,9 +22399,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22143,46 +22409,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22190,92 +22457,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22297,28 +22563,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22327,7 +22592,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22338,7 +22603,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22348,50 +22613,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22399,137 +22664,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22537,31 +22811,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22575,45 +22849,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22621,68 +22900,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22690,14 +22969,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22710,8 +22989,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22755,7 +23034,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30234,14 +30513,14 @@ msgid "Audio" msgstr "Lyd" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30261,40 +30540,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30302,37 +30585,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30340,7 +30623,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30350,79 +30633,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30430,7 +30711,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30442,39 +30723,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30483,11 +30764,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30495,51 +30776,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30547,55 +30828,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30604,11 +30885,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30888,10 +31169,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32750,1532 +33027,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40267,7 +39018,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40655,226 +39406,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47320,9 +46190,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47376,7 +46246,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51972,6 +50842,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/de.po b/weblate/de.po index 43960cfd4e..09fedae1b8 100644 --- a/weblate/de.po +++ b/weblate/de.po @@ -25,7 +25,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-06 07:06+0000\n" "Last-Translator: kdankert \n" "Language-Team: German ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3588,109 +3592,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3698,55 +3702,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3754,57 +3758,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3814,17 +3818,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3832,7 +3836,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3840,55 +3844,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "Partikel" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3896,24 +3900,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6660,7 +6664,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6683,7 +6687,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6694,8 +6698,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6717,7 +6721,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6781,27 +6785,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6809,17 +6813,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6829,54 +6833,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6885,7 +6889,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6894,18 +6898,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6913,7 +6917,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6921,14 +6925,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6938,60 +6942,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -7001,11 +7005,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -7013,7 +7017,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -7021,15 +7025,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -7038,38 +7042,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -7078,20 +7082,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -7099,15 +7103,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7256,7 +7260,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7296,7 +7300,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7340,7 +7344,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7364,7 +7368,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7400,7 +7404,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7420,14 +7424,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7437,11 +7441,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7449,7 +7453,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7463,7 +7467,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7478,7 +7482,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7602,7 +7606,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7644,8 +7648,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7679,7 +7683,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7705,19 +7709,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7742,7 +7746,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7765,7 +7769,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7783,7 +7787,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7800,8 +7804,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7836,7 +7840,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -8007,7 +8011,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -8017,25 +8021,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -8056,183 +8060,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Lizenz" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "Windows, macOS, X11 (Linux, \\*BSD)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8240,17 +8244,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8258,139 +8262,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8400,7 +8404,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8410,69 +8414,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8480,125 +8484,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8606,7 +8610,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8630,7 +8634,7 @@ msgstr "Pfad" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8667,79 +8671,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8747,36 +8751,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -12373,10 +12377,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -13430,7 +13434,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -14077,6 +14081,259 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +#, fuzzy +msgid "Export of Blender materials" +msgstr "Exporte" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Es gibt keine Nutzungsbeschränkung für Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "Art" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14978,136 +15235,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -15115,113 +15386,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -15230,15 +15501,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -15246,34 +15517,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -15281,15 +15552,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "FPS" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -15297,51 +15568,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -15349,102 +15620,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -15452,44 +15723,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -17398,7 +17669,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -17423,8 +17694,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -17459,7 +17730,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -17504,16 +17775,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17609,7 +17880,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17738,7 +18009,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17878,7 +18149,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17893,7 +18164,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17993,44 +18264,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -18039,17 +18310,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -18061,7 +18332,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -18073,25 +18344,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -18099,61 +18370,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -18164,29 +18435,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Werkzeuge" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -18303,9 +18574,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -18314,8 +18585,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -18554,8 +18825,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18814,7 +19085,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18862,7 +19133,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -19000,7 +19271,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -19033,10 +19304,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -19469,16 +19736,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -19521,6 +19788,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19844,8 +20112,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19859,14 +20127,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19898,67 +20166,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19967,334 +20235,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -20302,11 +20570,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -20315,30 +20583,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -20346,11 +20614,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -20360,11 +20628,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Tiefe" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -20373,66 +20641,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -20440,38 +20708,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -20482,13 +20750,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -20531,8 +20799,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -20543,7 +20811,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -20571,56 +20839,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20628,26 +20896,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20655,23 +20923,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20680,129 +20948,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20810,111 +21077,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20944,61 +21211,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -21006,7 +21274,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -21014,42 +21282,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -21057,31 +21325,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -21096,186 +21364,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -21289,38 +21557,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -21329,44 +21597,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -21374,27 +21642,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -21402,7 +21670,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -21410,13 +21678,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -21425,113 +21693,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -21539,110 +21807,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21650,12 +21918,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21668,213 +21936,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21882,38 +22150,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21923,149 +22191,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -22073,143 +22341,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -22217,78 +22486,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -22329,10 +22598,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -22384,11 +22653,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -22424,7 +22693,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -22435,8 +22704,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -22451,23 +22720,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -22478,7 +22748,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22692,9 +22962,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22702,46 +22972,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22749,92 +23020,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22856,28 +23126,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22886,7 +23155,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22897,7 +23166,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22907,50 +23176,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22958,137 +23227,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -23096,31 +23374,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -23134,45 +23412,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -23180,68 +23463,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -23249,14 +23532,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -23269,8 +23552,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -23314,7 +23597,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30797,14 +31080,14 @@ msgid "Audio" msgstr "Audio" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30824,40 +31107,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30865,37 +31152,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30903,7 +31190,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30913,79 +31200,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30993,7 +31278,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -31005,39 +31290,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -31046,11 +31331,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -31058,51 +31343,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -31110,55 +31395,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -31167,11 +31452,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -31451,10 +31736,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -33313,1532 +33594,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40830,7 +39585,7 @@ msgid "Or alternatively, set it via function:" msgstr "Oder, alternativ, gesetzt durch eine Funktion:" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -41219,226 +39974,347 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 +#, fuzzy msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" +"Für mehr Informationen über Events, siehe :ref:`doc_inputevent` Tutorial." + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47885,9 +46761,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47941,7 +46817,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -52539,6 +51415,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/el.po b/weblate/el.po index 7d4a7a534f..df837b1ca2 100644 --- a/weblate/el.po +++ b/weblate/el.po @@ -10,7 +10,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-05-06 16:37+0000\n" "Last-Translator: George Tsiamasiotis \n" "Language-Team: Greek ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3511,109 +3513,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3621,55 +3623,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3677,57 +3679,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3737,17 +3739,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3755,7 +3757,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3763,55 +3765,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "Σωματίδια" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3819,24 +3821,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6581,7 +6583,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6604,7 +6606,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6615,8 +6617,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6638,7 +6640,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6702,27 +6704,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6730,17 +6732,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6750,54 +6752,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6806,7 +6808,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6815,18 +6817,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6834,7 +6836,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6842,14 +6844,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6859,60 +6861,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6922,11 +6924,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6934,7 +6936,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6942,15 +6944,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6959,38 +6961,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6999,20 +7001,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -7020,15 +7022,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7177,7 +7179,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7217,7 +7219,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7261,7 +7263,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7285,7 +7287,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7321,7 +7323,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7341,14 +7343,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7358,11 +7360,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7370,7 +7372,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7384,7 +7386,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7399,7 +7401,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7523,7 +7525,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7565,8 +7567,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7600,7 +7602,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7626,19 +7628,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7663,7 +7665,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7686,7 +7688,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7704,7 +7706,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7721,8 +7723,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7757,7 +7759,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7928,7 +7930,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7938,25 +7940,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7977,183 +7979,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Άδεια" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "Windows, MacOS, X11 (Linux, \\*BSD)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8161,17 +8163,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8179,139 +8181,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8321,7 +8323,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8331,69 +8333,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8401,125 +8403,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8527,7 +8529,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8551,7 +8553,7 @@ msgstr "Διαδρομή" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8588,79 +8590,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8668,36 +8670,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11948,10 +11950,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -13002,7 +13004,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13647,6 +13649,258 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Δεν υπάρχουν περιορισμοί χρήσης στην Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "Τύπος" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14548,136 +14802,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14685,113 +14953,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14800,15 +15068,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14816,34 +15084,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14851,15 +15119,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "FPS" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14867,51 +15135,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14919,102 +15187,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -15022,44 +15290,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16968,7 +17236,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16993,8 +17261,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -17029,7 +17297,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -17074,16 +17342,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17179,7 +17447,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17308,7 +17576,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17448,7 +17716,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17463,7 +17731,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17563,44 +17831,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17609,17 +17877,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17631,7 +17899,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17643,25 +17911,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17669,61 +17937,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17734,29 +18002,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Εργαλεία" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17873,9 +18141,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17884,8 +18152,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -18124,8 +18392,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18384,7 +18652,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18432,7 +18700,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18570,7 +18838,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18603,10 +18871,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -19039,16 +19303,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -19091,6 +19355,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19414,8 +19679,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19429,14 +19694,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19468,67 +19733,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19537,334 +19802,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19872,11 +20137,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19885,30 +20150,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19916,11 +20181,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19930,11 +20195,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Βάθος" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19943,66 +20208,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -20010,38 +20275,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -20052,13 +20317,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -20101,8 +20366,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -20113,7 +20378,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -20141,56 +20406,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20198,26 +20463,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20225,23 +20490,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20250,129 +20515,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20380,111 +20644,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20514,61 +20778,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20576,7 +20841,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20584,42 +20849,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20627,31 +20892,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20666,186 +20931,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20859,38 +21124,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20899,44 +21164,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20944,27 +21209,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20972,7 +21237,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20980,13 +21245,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20995,113 +21260,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -21109,110 +21374,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21220,12 +21485,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21238,213 +21503,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21452,38 +21717,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21493,149 +21758,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21643,143 +21908,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21787,78 +22053,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21899,10 +22165,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21954,11 +22220,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21994,7 +22260,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -22005,8 +22271,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -22021,23 +22287,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -22048,7 +22315,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22262,9 +22529,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22272,46 +22539,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22319,92 +22587,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22426,28 +22693,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22456,7 +22722,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22467,7 +22733,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22477,50 +22743,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22528,137 +22794,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22666,31 +22941,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22704,45 +22979,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22750,68 +23030,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22819,14 +23099,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22839,8 +23119,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22884,7 +23164,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30363,14 +30643,14 @@ msgid "Audio" msgstr "Ήχος" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30390,40 +30670,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30431,37 +30715,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30469,7 +30753,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30479,79 +30763,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30559,7 +30841,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30571,39 +30853,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30612,11 +30894,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30624,51 +30906,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30676,55 +30958,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30733,11 +31015,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -31017,10 +31299,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32879,1532 +33157,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40396,7 +39148,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40784,226 +39536,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47449,9 +46320,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47505,7 +46376,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -52102,6 +50973,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/es.po b/weblate/es.po index 058e5fe35c..2573743238 100644 --- a/weblate/es.po +++ b/weblate/es.po @@ -36,7 +36,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-15 21:44+0000\n" "Last-Translator: Javier Ocampos \n" "Language-Team: Spanish ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " @@ -4351,23 +4358,23 @@ msgstr "" "que mostrará no estará cubierta por ningún elemento como el jugador o los " "enemigos." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "El HUD mostrará la siguiente información:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "Puntuación, cambiado por ``ScoreTimer``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "Un mensaje como \"Game Over\" o \"Get Ready!\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "Un botón \"Start\" para comenzar el juego." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" @@ -4377,27 +4384,27 @@ msgstr "" "crear nuestra UI, usaremos dos tipos de nodos :ref:`Control " "`: :ref:`Label ` y :ref:`Button `." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "Cree los siguientes hijos del nodo ``HUD``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr ":ref:`Label ` llamado ``ScoreLabel``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr ":ref:`Label ` llamado ``MessageLabel``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr ":ref:`Button ` llamado ``StartButton``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr ":ref:`Timer ` llamado ``MessageTimer``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -4413,7 +4420,7 @@ msgstr "" "Representan la distancia del borde al ancla del nodo Control. Para más " "detalles, ver :ref:`doc_design_interfaces_with_the_control_nodes`." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" @@ -4421,7 +4428,7 @@ msgstr "" "Acomoda los nodos como se muestra debajo. Cliquea en el botón \"Disposición" "\" para configurar el anclaje del nodo Control:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" @@ -4429,97 +4436,97 @@ msgstr "" "Puedes arrastrar y ubicarlos manualmente o, para un modo más preciso, usa la " "siguiente configuración:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "ScoreLabel" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "``Disposición``: \"Centro Arriba\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "``Margin``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "Left: ``-25``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "Top: ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "Right: ``25``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "Bottom: ``100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "Text: ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "MessageLabel" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "``Disposición``: \"Centro\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "Izquierda: ``-200``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "Top: ``-150``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "Right: ``200``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "Bottom: ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "Text: ``Dodge the Creeps!``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "StartButton" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "``Disposición``: \"Centro Abajo\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "Left: ``-100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "Top: ``-200``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "Right: ``100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "Bottom: ``-100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "Text: ``Start``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -4531,11 +4538,11 @@ msgstr "" "Regular.ttf\". Para usar esta fuente, haz lo siguiente en los tres nodos " "``Control``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "Dentro de \"Custom Fonts\", seleccionar \"New DynamicFont\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " @@ -4546,18 +4553,18 @@ msgstr "" "cambiar el ``Size`` (tamaño) de la fuente. Un valor de ``64`` funcionará " "bien." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "Ahora agrega este script a ``HUD``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" "La señal ``start_game`` dirá al nodo ``Main`` que se ha presionado un botón." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " @@ -4567,7 +4574,7 @@ msgstr "" "como \"Get Ready\". En el ``MessageTimer``, ajustar el ``Wait Time`` en " "``2`` y la propiedad ``One Shot`` en \"Activado\"." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." @@ -4576,11 +4583,11 @@ msgstr "" "\" durante 2 segundos, luego volverá a la pantalla de título y mostrará el " "botón \"Start\"." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "Esta función se llamará en ``Main`` cuando el puntaje cambie." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." @@ -4588,11 +4595,11 @@ msgstr "" "Conecta la señal ``timeout()`` del ``MessageTimer`` y la señal ``pressed()`` " "de ``StartButton``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "Conectando HUD a Main" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -4604,7 +4611,7 @@ msgstr "" "``Player``, y colócala al final del árbol. El árbol completo debería verse " "así, así que asegúrate de que no falta nada:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" @@ -4612,7 +4619,7 @@ msgstr "" "Ahora conectaremos la funcionalidad de ``HUD`` a nuestro script ``Main``. " "Esto requiere unas pocas adiciones a la escena ``Main``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." @@ -4620,20 +4627,20 @@ msgstr "" "En el panel Node conecta la señal ``start_game`` de HUD a la función " "``new_game()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" "En``new_game()``, actualiza la puntuación y muestra el mensaje \"Get Ready\":" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" "En ``game_over()`` necesitaremos llamar la función correspondiente en " "``HUD``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" @@ -4641,7 +4648,7 @@ msgstr "" "Finalmente, agregua ``_on_ScoreTimer_timeout()`` para mantener la interfaz " "en sincronía al cambiar la puntuación:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." @@ -4649,11 +4656,11 @@ msgstr "" "Ahora está listo para jugar. Haga click en el botón \"Reproducir\". Deberás " "seleccionar una escena principal, selecciona ``Main.tscn``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "Finalizando" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " @@ -4663,12 +4670,12 @@ msgstr "" "están los pasos restantes para agregar más \"jugo\" y mejorar la experiencia " "de juego. Eres libre de expandir el juego con sus propias ideas." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "Imagen de fondo" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -4683,7 +4690,7 @@ msgstr "" "``ColorRect`` tiene una sola propiedad: ``Color``. Escoge el color que " "quieras y arrastra el borde del ``ColorRect`` para que cubra la pantalla." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." @@ -4691,11 +4698,11 @@ msgstr "" "También puedes agregar una imagen de fondo, si tienes una, utilizando un " "nodo ``Sprite``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "Efectos de sonido" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -4707,7 +4714,7 @@ msgstr "" "sonido: \"House In a Forest Loop.ogg\" para música de fondo y \"gameover.wav" "\" para cuando el jugador pierde." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -4719,7 +4726,7 @@ msgstr "" "uno, haz click en la propiedad ``Stream``, selecciona \"Load\" y escoge el " "archivo de audio correspondiente." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." @@ -4727,17 +4734,17 @@ msgstr "" "Para reproducir la música, agregua ``$Music.play()`` en la función " "``new_game()`` y ``$Music.stop()`` en ``game_over()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" "Finalmente, agregua ``$DeathSound.play()`` en la función ``game_over()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "Partículas" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " @@ -4747,7 +4754,7 @@ msgstr "" "al movimiento del jugador. Selecciona la escena ``Player`` y añade un nodo :" "ref:`Particles2D `, nómbralo ``Trail``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " @@ -4757,7 +4764,7 @@ msgstr "" "Tómate la libertad de experimentar y crear diferentes efectos. Para el " "efecto de este ejemplo, usaremos la siguiente configuración:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" @@ -4765,7 +4772,7 @@ msgstr "" "Deberás crear un ``Material`` haciendo click en ```` y luego en " "\"Nuevo ParticlesMaterial\". La configuración es la que se muestra debajo:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " @@ -4775,7 +4782,7 @@ msgstr "" "tomando el alfa (transparencia) del sprite desde 0.5 (semi transparente) a " "0.0 (completamente transparente)." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" @@ -4783,7 +4790,7 @@ msgstr "" "Haz click en \"Nuevo GradientTexture\", luego, dentro de \"Gradient\", " "seleccione \"Nuevo Gradient\". Verás una ventana como esta:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -4795,7 +4802,7 @@ msgstr "" "seleccionar el color. Para el primer color, ajusta el valor ``A`` (alfa) a " "la mitad. Para el segundo, llévalo a ``0``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." @@ -4803,11 +4810,11 @@ msgstr "" "Vea :ref:`Particles2D ` para más detalles sobre el uso " "de efectos de partículas." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "Archivos de Proyecto" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" @@ -4816,7 +4823,7 @@ msgstr "" "kidscancode/Godot3_dodge/releases" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "Exportar" @@ -8728,7 +8735,8 @@ msgstr "" "los nodos para que escuche el que seleccionaste." #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +#, fuzzy +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" "La primera sección enlista las señales personalizadas definidas en ``player." "GD``:" @@ -8750,12 +8758,13 @@ msgid "We're connecting to the health\\_changed signal" msgstr "Nos estamos conectando a la señal health\\_changed" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:234 +#, fuzzy msgid "" "Select ``health_changed`` and click on the Connect button in the bottom " "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -8772,9 +8781,10 @@ msgid "The Connect Signal window with the GUI node selected" msgstr "La ventana Conectando Señal con el nodo GUI seleccionado" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 +#, fuzzy msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" "Opcionalmente se pueden conectar nodos desde el código. Pero hacerlo desde " "el editor tiene dos ventajas:" @@ -8794,6 +8804,7 @@ msgstr "" "panel de Escenas" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:253 +#, fuzzy msgid "" "At the bottom of the window you will find the path to the node you selected. " "We're interested in the second row called \"Method in Node\". This is the " @@ -8802,7 +8813,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" "En la parte inferior de la ventana se encuentra la ruta al nodo " "seleccionado. Nos interesa la segunda fila llamada \"Method in Node\". Este " @@ -8900,22 +8911,22 @@ msgstr "" "``_on_Player_health_changed``. Solo necesita new\\_value como único " "argumento:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "Este método necesita hacer:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" "establece ``text`` del nodo ``Number`` en ``new_value`` convertido en un " "string" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "establece el ``value`` de ``TextureProgress`` en ``new_value``" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " @@ -8925,7 +8936,7 @@ msgstr "" "La propiedad ``Number``'s ``text`` requiere un string por lo que no podemos " "asignarlo a ``new_value`` directamente" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -8937,7 +8948,7 @@ msgstr "" "del juego. Pulsa F5 para probar el juego: ¡la barra de vida se actualiza con " "cada ataque!" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" @@ -8945,11 +8956,11 @@ msgstr "" "Tanto el nodo Number como el TextureProgress se actualizan cuando el jugador " "recibe un golpe" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "Animar la pérdida de vida con el nodo Tween" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -8965,7 +8976,7 @@ msgstr "" "puede animar la salud del ``TextureProgress`` desde su nivel actual hasta el " "nuevo valor de ``health`` del ``Player`` cuando el personaje sufre daños." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " @@ -8975,7 +8986,7 @@ msgstr "" "variable ``tween``. Ahora vamos a usarlo. Tenemos que hacer algunos cambios " "en ``update_health``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" @@ -8983,35 +8994,35 @@ msgstr "" "Usaremos el método ``Tween`` del nodo ``interpolate_property``. Se necesitan " "siete argumentos:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "Una referencia al nodo que posee la propiedad para animar" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "El identificador de la propiedad es un string" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "El valor inicial" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "El valor final" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "Duración de la animación en segundos" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "El tipo de transición" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "La facilidad de uso en combinación con la ecuación." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." @@ -9020,7 +9031,7 @@ msgstr "" "relajación <#>`__. Esto controla cómo evoluciona el valor desde el punto de " "inicio hasta el punto final." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -9034,7 +9045,7 @@ msgstr "" "número, pero no para animar texto directamente. Vamos a usarlo para animar " "una nueva variable ``GUI`` llamada ``animated_health``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -9048,11 +9059,11 @@ msgstr "" "``animated_health``. Llama al método ``Tween`` del nodo " "``interpolate_property``:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "Vamos a interrumpir la llamada:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " @@ -9062,7 +9073,7 @@ msgstr "" "Interpolate_property toma el nombre de la propiedad como un string. Por eso " "lo escribimos como ``\"animated_health\"``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -9075,7 +9086,7 @@ msgstr "" "``health_changed``: ese es el ``new_value``. Y ``0.6`` es la duración de la " "animación en segundos." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -9087,7 +9098,7 @@ msgstr "" "hace nada con una transición lineal, pero debemos proporcionar este último " "argumento si no queremos recibir un error." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " @@ -9097,7 +9108,7 @@ msgstr "" "``tween.start()``. Sólo tenemos que hacerlo una vez si el nodo no está " "activo. Añade este código después de la última línea:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -9114,11 +9125,11 @@ msgstr "" "controladas por código. Para animaciones hechas a mano, echa un vistazo a " "`AnimationPlayer`." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "Asignar animated\\_health a LifeBar" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." @@ -9126,11 +9137,11 @@ msgstr "" "Ahora la variable ``animated_health`` anima pero ya no se actualizan los " "nodos ``Bar`` y ``Number`` existentes. Solucionemos esto." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "Hasta ahora, el método update\\_health se ve así:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " @@ -9141,7 +9152,7 @@ msgstr "" "los nodos ``Number`` y ``TextureProgress`` como antes, dentro de " "``_process``:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." @@ -9149,7 +9160,7 @@ msgstr "" "`number_label` y `bar` son variables que guardan referencias a los nodos " "`Number` y `TextureProgress`." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " @@ -9160,11 +9171,11 @@ msgstr "" "del juego, sería bueno que la barra de vida se animara de una manera más " "atractiva." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "La animación es suave pero el número está roto" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " @@ -9174,15 +9185,15 @@ msgstr "" "variable local llamada ``round_value`` para guardar el valor redondeado " "``animated_health``. Luego asígnalo a ``number_label.text`` y ``bar.value``:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "Intenta jugar de nuevo para ver una bonita animación de bloques." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "Gracias a redondear animated\\_health matamos dos pájaros de un tiro" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -9198,11 +9209,11 @@ msgstr "" "gradualmente es un truco. Hace que el GUI se sienta vivo. Si el ``Player`` " "recibe 3 de daño, ocurre en un instante." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "Desvanecer la barra cuando el jugador muere" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -9215,7 +9226,7 @@ msgstr "" "mismo nodo ``Tween`` ya que gestiona múltiples animaciones en paralelo por " "nosotros." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -9227,15 +9238,15 @@ msgstr "" "2D. Selecciona el nodo ``Player`` en el panel de Escenas y haz clic en la " "pestaña Nodos junto al Inspector." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "Busca la señal ``died``, selecciónala y haz clic en el botón Conectar." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "La señal ya debería tener al enemigo conectado" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -9249,11 +9260,11 @@ msgstr "" "Conectar en la parte inferior de la ventana. Esto te llevará al archivo " "``GUI.gd`` en el Área de Trabajo de Scripts." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "Se debe obtener estos valores en la ventana Conectando Señal" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " @@ -9263,7 +9274,7 @@ msgstr "" "información, emitimos una nueva señal. Úsalas sabiamente: mientras más " "conexiones añadas, serán más difíciles de seguir." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." @@ -9272,7 +9283,7 @@ msgstr "" "propiedad ``modulate``. ``modulate`` es un ``Color``que multiplica los " "colores de nuestras texturas." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " @@ -9282,7 +9293,7 @@ msgstr "" "UI heredan de él. Este permite alternar la visiblidad del nodo, asignarle un " "shader y modificarlo usando un color mediante `modulate`." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " @@ -9293,7 +9304,7 @@ msgstr "" "obscurece. Si reducimos el valor del canal alfa la interfaz se va " "desvaneciendo." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -9308,7 +9319,7 @@ msgstr "" "``end_color``. Usa el constructor ``Color()`` para crear dos valores " "``Color``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " @@ -9318,7 +9329,7 @@ msgstr "" "respectivamente ``1.0`` y ``0.0``en ``start_color`` y ``end_color``, es el " "canal alfa." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" @@ -9326,7 +9337,7 @@ msgstr "" "Luego debemos llamar nuevamente al método ``interpolate_property`` del nodo " "``Tween``:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -9338,16 +9349,16 @@ msgstr "" "transición lineal. Aquí también, debido a que la transición es lineal, la " "relajación no importa. Aquí está el método completo ``_on_Player_died``:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" "Y eso es todo ¡Ahora puedes jugar el juego para ver el resultado final!" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "El resultado final ¡Felicidades por llegar hasta aquí!" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -9536,7 +9547,8 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "El fotograma clave sera agregado al editor de animaciones:" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +#, fuzzy +msgid "Move the editor cursor to the end by clicking here:" msgstr "Mueva el cursor al final haciendo click aquí:" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -9580,9 +9592,10 @@ msgid "Nodes and resources" msgstr "Nodos y recursos" #: ../../docs/getting_started/step_by_step/resources.rst:9 +#, fuzzy msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -9645,9 +9658,10 @@ msgstr "" "contenedores de datos, por lo que no es necesario duplicarlos." #: ../../docs/getting_started/step_by_step/resources.rst:42 +#, fuzzy msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -9679,8 +9693,9 @@ msgstr "" "nodo :ref:`Sprite `:" #: ../../docs/getting_started/step_by_step/resources.rst:61 +#, fuzzy msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -9729,9 +9744,10 @@ msgstr "" "es usar load(), de este modo:" #: ../../docs/getting_started/step_by_step/resources.rst:101 +#, fuzzy msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" "El segundo modo es más óptimo, pero sólo funciona con una cadena constante " "como parámetro, porque carga el recurso en tiempo de compilación." @@ -9758,7 +9774,7 @@ msgstr "" "Para obtener una instancia de la escena, se debe usar el método :ref:" "`PackedScene.instance() `." -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " @@ -9768,7 +9784,7 @@ msgstr "" "las propiedades) y retorna el nodo raíz de la escena, el cual puede ser " "agregado a cualquier otro nodo." -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -9785,11 +9801,11 @@ msgstr "" "que, como siempre, imágenes, mallas, etc. son compartidas entre las " "instancias de escena." -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "Liberando recursos" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -9802,7 +9818,7 @@ msgstr "" "u otros recursos, cuando un nodo es eliminado o liberado, todos los recursos " "hijos también son liberados." -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -9817,9 +9833,10 @@ msgid "File system" msgstr "Sistema de archivos" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 +#, fuzzy msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -9845,7 +9862,7 @@ msgstr "" "sistema de archivos." #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "Implementación" @@ -10013,11 +10030,12 @@ msgstr "" "nueva ubicación del recurso." #: ../../docs/getting_started/step_by_step/filesystem.rst:103 +#, fuzzy msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" "Para evitar esto, realiza todas tus operaciones de mover, borrar y renombrar " "desde Godot, en el panel de Sistema de Archivos. Nunca mueva assets desde " @@ -10078,10 +10096,11 @@ msgstr "" "entran al *scene tree*." #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 +#, fuzzy msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" "Este concepto merece un poco más de detalle. De hecho, el sistema de escena " @@ -10132,8 +10151,9 @@ msgstr "" "Godot, escribir tu propio MainLoop tiene poco sentido." #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 +#, fuzzy msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" "Una de las maneras de explicar cómo funciona Godot, es que se trata de un " @@ -10167,9 +10187,10 @@ msgstr "" "importantes:" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 +#, fuzzy msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" "Contiene el :ref:`Viewport ` raíz, al cual se añade una " @@ -10177,16 +10198,18 @@ msgstr "" "Escenas* (más información a continuación)" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 +#, fuzzy msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" "Contiene información sobre los grupos, y posee medios para llamar a todos " "los nodos de un grupo u obtener una lista de ellos." #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 +#, fuzzy msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" "Contiene alguna funcionalidad de estado global, como configurar el modo de " @@ -10216,10 +10239,11 @@ msgstr "" "diferentes:" #: ../../docs/getting_started/step_by_step/scene_tree.rst:88 +#, fuzzy msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" "Este nodo contiene el viewport principal, cualquier otro elemento es un " @@ -10250,8 +10274,9 @@ msgstr "" "principal, este se vuelve parte del *Árbol de escenas*." #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 +#, fuzzy msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" "Esto significa que, como se explicó en los tutoriales anteriores, se " @@ -10274,8 +10299,9 @@ msgid "Tree order" msgstr "Orden del árbol" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 +#, fuzzy msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -10294,10 +10320,11 @@ msgid "A scene is loaded from disk or created by scripting." msgstr "Una escena es cargada desde disco o creada mediante scripting." #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 +#, fuzzy msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" "El nodo raíz de esa escena (sólo una raíz, ¿recuerdas?) se añade como hijo " "del Viewport \"raíz\" (de Árbol de Escenas), o a cualquier hijo o nieto del " @@ -10344,8 +10371,9 @@ msgstr "" "change_scene() `:" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 +#, fuzzy msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -10578,7 +10606,7 @@ msgstr "" "La siguiente es la función para cambiar la escena. Esta función libera la " "escena actual y la reemplaza por la solicitada." -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -10595,7 +10623,7 @@ msgstr "" "momento posterior cuando no se esté ejecutando ningún código de la escena " "actual." -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" @@ -10603,13 +10631,13 @@ msgstr "" "Finalmente, lo único que falta es completar las funciones vacías en scene_a." "gd y scene_b.gd:" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "y" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" @@ -10617,7 +10645,7 @@ msgstr "" "Ahora, si ejecutas el proyecto ¡puedes cambiar entre ambas escenas pulsando " "el botón!" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -10643,68 +10671,68 @@ msgstr "" "vista de un usuario Unity y apunta a ayudarte a migrar tu experiencia actual " "en Unity al mundo de Godot." -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "Diferencias" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "Unity" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "Godot" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Licencia" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" "Licencia propietaria, cerrada y libre con límites de ingresos y " "restricciones de uso" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" "Licencia MIT, libre y completamente open source sin ninguna restricción" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "OS (editor)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "Windows, macOS, Linux (no oficial y sin soporte)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "Windows, macOS, X11 (Linux, \\*BSD)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "OS (exportar)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "**Escritorio:** Windows, macOS, Linux" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "**Móvil:** Android, iOS, Windows Phone, Tizen" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "**Web:** WebAssembly o asm.js" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "**Consolas:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" @@ -10712,43 +10740,43 @@ msgstr "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "**TV:** Android TV, Samsung SMART TV, tvOS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "**Escritorio:** Windows, macOS, X11" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "**Móvil:** Android, iOS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "**Web:** WebAssembly" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "**Consolas:** Ver :ref:`doc_consoles`" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "**VR:** Oculus Rift, SteamVR" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "Sistema de escenas" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "Componente/Escena (GameObject > Componente)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "Prefabs" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" @@ -10756,56 +10784,56 @@ msgstr "" ":ref:`Árbol de escenas y nodos `, permitiendo que las " "escenas se aniden y/o hereden otras escenas" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "Herramientas de terceros" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "Visual Studio o VS Code" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr ":ref:`Los editores externos son posibles `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" ":ref:`Android SDK para exportación a Android `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "Funciones destacadas" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "Gran comunidad" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "Gran almacén de recursos" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "Sistema de Escenas" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr ":ref:`Canalización de Animaciones`" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr ":ref:`Shaders fáciles de escribir `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "Depuración en el dispositivo" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "El editor" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " @@ -10815,7 +10843,7 @@ msgstr "" "permite construir tus juegos. Las imágenes de abajo muestran ambos editores " "con bloques de color para indicar funcionalidades comunes." -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." @@ -10823,13 +10851,14 @@ msgstr "" "Ten en cuenta que el editor Godot te permite acoplar cada panel al lado del " "editor de escenas que desees." -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#, fuzzy msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" "Aunque ambos editores pueden parecer similares, hay muchas diferencias bajo " "la superficie. Ambos permiten organizar el proyecto utilizando el sistema de " @@ -10838,7 +10867,7 @@ msgstr "" "contribuye a que Godot sea mucho más amigable con sistemas VCS como Git, " "Subversion o Mercurial." -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -10850,13 +10879,14 @@ msgstr "" "es más descriptivo visualmente. En otras palabras, es más fácil entender lo " "que hace una escena específica a primera vista." -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 +#, fuzzy msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" "El Inspector en Godot es más minimalista y está diseñado para mostrar sólo " @@ -10867,7 +10897,7 @@ msgstr "" "colores, texturas, enumeraciones o incluso enlaces a recursos en tiempo real " "sin necesidad de utilizar código." -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -10880,10 +10910,11 @@ msgstr "" "se ejecutan dentro del editor (pero el árbol y los objetos todavía se pueden " "explorar en la ventana del depurador)." -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 +#, fuzzy msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" @@ -10892,21 +10923,23 @@ msgstr "" "futuro; es posible actualmente mostrar aparatos de colisión en el juego " "actual), pero a cambio, tiene varias ventajas:" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 +#, fuzzy msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." +"project, close the project, and then reload the previous state)." msgstr "" "La velocidad con la que el proyecto inicia, así como la velocidad con la que " "se cierra es rápida (En cambio, Unity necesita guardar, iniciar el proyecto, " "cerrar el proyecto, y después recargar el estado anterior)." -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 +#: ../../docs/getting_started/editor/unity_to_godot.rst:80 +#, fuzzy msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." msgstr "" "La edición en tiempo real es mucho mas útil, porque los cambios hechos " "dentro del editor toman efecto inmediatamente en el juego. Estos cambios no " @@ -10914,50 +10947,55 @@ msgstr "" "permite fantásticos flujos de trabajo, como crear niveles mientras juegas en " "ellos." -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +#, fuzzy +msgid "The editor is more stable because the game runs in a separate process." msgstr "" "El editor es mas estable, porque el juego corre en un proceso separado." -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#, fuzzy msgid "" "Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." msgstr "" "Finalmente, la barra de herramientas superior incluye un menú para " "depuración remota. Estas opciones hacen fácil desplegar a un dispositivo " "(teléfono conectado, tableta, o a un navegador vía HTML5), y depurar/editar " "en tiempo real en el una vez el juego a sido exportado." -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 msgid "The scene system" msgstr "El sistema de escenas" -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#, fuzzy msgid "" -"This is the most important difference between Unity and Godot, and actually " +"This is the most important difference between Unity and Godot and, actually, " "the favourite feature of most Godot users." msgstr "" "Esta es la diferencia mas importante entre Unity y Godot, y actualmente " "también la funcionalidad favorita de la mayoría de los usuarios de Godot." -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#, fuzzy msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." msgstr "" "El sistema de escenas de Unity consiste en integrar todos los recursos " "necesarios en una escena y enlazarlos entre sí mediante la configuración de " "componentes y scripts." -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +#, fuzzy msgid "" "Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." msgstr "" "El sistema de escenas de Godot es diferente: en realidad consiste en un " "árbol hecho de nodos. Cada nodo tiene un propósito: Sprite, Mesh, Light... " @@ -10966,7 +11004,7 @@ msgstr "" "escena principal. Esto significa que se puede componer una escena completa " "con escenas diferentes, almacenadas en archivos diferentes." -#: ../../docs/getting_started/editor/unity_to_godot.rst:80 +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" @@ -10974,29 +11012,30 @@ msgstr "" "Por ejemplo, piensa en un nivel de un juego de plataformas. Verías que está " "compuesto de múltiples elementos:" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "Bloques" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "Mondedas" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "El jugador" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "Los enemigos" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#, fuzzy msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" "En Unity, pondrías todos los GameObjects en la escena: el jugador, múltiples " @@ -11007,7 +11046,7 @@ msgstr "" "elementos de la escena para que puedan colisionar. Este principio es " "diferente en Godot." -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." @@ -11015,11 +11054,11 @@ msgstr "" "En Godot, dividirías toda tu escena en 3 escenas separadas, más pequeñas, " "que luego colocarías en la escena principal." -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "**Primero, una escena para el jugador únicamente.**" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " @@ -11030,11 +11069,11 @@ msgstr "" "las texturas o imágenes que forman las varias animaciones (por ejemplo, la " "animación de andar)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "**Segundo, una escena para el Enemigo.**" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " @@ -11045,18 +11084,19 @@ msgstr "" "gestiona la IA, principalmente) y las texturas de sprite usadas por el " "AnimatedSprite." -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "**Por último, la escena del nivel.**" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#, fuzzy msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" "Está compuesta de muros/paredes (para plataformas), Monedas (para que el " "jugador las recoja) y un cierto numero de instancias de la escena del " @@ -11066,7 +11106,7 @@ msgstr "" "del nivel. Por supuesto, puedes establecer diferentes propiedades para cada " "nodo Enemigo (como cambiar su color por ejemplo)." -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -11082,7 +11122,7 @@ msgstr "" "relacionados con 2D), \"Spatial\" (tipo raíz de todos los nodos relacionados " "con 3D) o \"Control\" (tipo raíz de todos los nodos relacionados con GUI)." -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -11098,7 +11138,7 @@ msgstr "" "colisión. Godot dispone de varios nodos de tipos de colisión, dependiendo " "del uso (ver :ref:`Physics introduction `)." -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " @@ -11108,9 +11148,10 @@ msgstr "" "potencialmente este sistema la profundidad del árbol de la escena? Además, " "Unity permite organizar GameObjects poniéndolos en GameObjects vacíos." -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#, fuzzy msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" @@ -11119,12 +11160,13 @@ msgstr "" "\"Objetos de Juego\", pero que proporcionan a sus hijos sus propias " "capacidades: esto es herencia." -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 +#, fuzzy msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" @@ -11136,20 +11178,21 @@ msgstr "" "cualquier nodo. Poner múltiples nodos en un GameObject vacío en Unity no " "proporciona la misma posibilidad, aparte de una organización visual." -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 +#, fuzzy msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" "Estos son los conceptos más importantes que se deben recordar: \"nodo\", " "\"nodo padre\" y \"nodo hijo\"." -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "Organización del proyecto" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " @@ -11159,10 +11202,11 @@ msgstr "" "una arquitectura de proyecto. Cualquier solución funcionará para Unity y " "Godot, así que este punto tiene una importancia menor." -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#, fuzzy msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" @@ -11171,12 +11215,13 @@ msgstr "" "que contiene varias carpetas, una por tipo de activo: Audio, Graphics, " "Models, Materials, Scripts, Scenes, etc." -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 +#, fuzzy msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" "Como se ha descrito anteriormente, el sistema de escenas Godot permite " "dividir escenas en escenas más pequeñas. Dado que cada escena y subescena es " @@ -11184,11 +11229,11 @@ msgstr "" "proyecto de forma un poco diferente. Este wiki proporciona información al " "respecto: :ref:`doc_project_organization`." -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "¿Dónde están mis prefabs?" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -11200,15 +11245,16 @@ msgstr "" "escena es único, pero todos tienen las mismas propiedades definidas por el " "prefab." -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 +#, fuzzy msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" "Godot no proporciona prefabs como tal, pero esta funcionalidad se encuentra " "disponible gracias al sistema de escenas: como vimos el sistema de escenas " @@ -11219,16 +11265,17 @@ msgstr "" "Sin embargo, cualquier cambio que se realice en la instancia no tendrá " "ningún impacto en la escena `plantilla'." -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 +#, fuzzy msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" "Para ser precisos, se pueden modificar los parámetros de la instancia en el " "panel Inspector. Sin embargo, los nodos que componen esta instancia están " @@ -11240,11 +11287,11 @@ msgstr "" "añadir nuevos hijos a todas las instancias de tu escena `plantilla', " "entonces necesitas añadirlo una vez en la escena `plantilla'." -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "Correspondencia del glosario" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" @@ -11252,15 +11299,15 @@ msgstr "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "Scripting: GDScript, C# y Visual Script" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "Diseño" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." @@ -11268,15 +11315,17 @@ msgstr "" "Como ya sabrás, Unity soporta C#. C# se beneficia de su integración con " "Visual Studio y otras características, como el tipado estático." -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 +#, fuzzy msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" "Godot proporciona su propio lenguaje de scripting, ref:`GDScript " "` así como soporte para :ref:`Visual Script ` y :ref:`FAQ `_. GDScript " "está fuertemente unido a la API de Godot, pero es fácil de aprender." -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 +#, fuzzy msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" @@ -11298,19 +11348,20 @@ msgstr "" "un script para que reaccione a los controles del jugador y otro para que " "controle su lógica de juego específica." -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 +#, fuzzy msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" "En Godot, sólo puedes adjuntar un script por nodo. Se puede utilizar un " "archivo GDScript externo o incluirlo directamente en el nodo. Si necesitas " "adjuntar más scripts a un nodo, entonces puedes considerar dos soluciones, " "dependiendo de tu escena y de lo que quieras lograr:" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." @@ -11318,7 +11369,7 @@ msgstr "" "puedes añadir un nuevo nodo entre tu nodo de destino y su padre actual, y " "luego añadir un script a este nuevo nodo." -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." @@ -11326,24 +11377,26 @@ msgstr "" "o bien, puedes dividir tu nodo objetivo en varios hijos y adjuntar un script " "a cada uno de ellos." -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 +#, fuzzy msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" "Como puedes ver, es muy sencillo convertir un árbol de escenas en un " "desastre. Por eso es importante tener una auténtica reflexión, y considerar " "dividir una escena compleja en múltiples ramas más pequeñas." -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "Conexiones : grupos y señales" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 +#, fuzzy msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" @@ -11353,13 +11406,13 @@ msgstr "" "nodos que contiene este grupo! Esto se explica en :ref:`esta página " "`." -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 +#, fuzzy msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" "¡Pero hay más! Ciertos nodos emiten señales cuando ocurren ciertas acciones. " "Se pueden conectar estas señales para llamar a una función específica cuando " @@ -11367,11 +11420,11 @@ msgstr "" "y enviarlas cuando quieras. Esta característica está documentada `aquí <../" "scripting/gdscript/gdscript_basics.html#signals>`_." -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "Usando Godot en C++" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -11383,7 +11436,7 @@ msgstr "" "este momento. Por ejemplo, puedes considerar el editor de Godot Engine como " "un \"juego\" escrito en C++ usando la API de Godot." -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -11414,8 +11467,9 @@ msgid "Path" msgstr "Ruta" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 +#, fuzzy msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -11464,33 +11518,35 @@ msgstr "" msgid "Creating a project" msgstr "Creación de un proyecto" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 +#, fuzzy msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" "Para crear un proyecto desde la línea de comandos, navega hasta el lugar " "deseado y crea un archivo project.godot vacío." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "El proyecto ahora puede abrirse con Godot." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "Ejecutar el editor" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 +#, fuzzy msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" "Ejecutar el editor se hace ejecutando Godot con el flag ``-e``. Esto debe " "hacerse desde el directorio del proyecto, o desde un subdirectorio, de lo " "contrario el comando se ignora y aparece el gestor de proyectos." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." @@ -11498,26 +11554,27 @@ msgstr "" "Si una escena ha sido creada y guardada, puede ser editada más tarde " "ejecutando el mismo código con esa escena como argumento." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "Borrar una escena" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 +#, fuzzy msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" "Godot es amigo de tu sistema de archivos, y no creará archivos de metadatos " "adicionales, simplemente usa ``rm`` para borrar un archivo. Asegúrate de que " "nada hace referencia a esa escena, de lo contrario se producirá un error al " "abrirla." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "Ejecutar el juego" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." @@ -11525,7 +11582,7 @@ msgstr "" "Para ejecutar el juego, simplemente ejecuta Godot dentro del directorio o " "subdirectorio del proyecto." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." @@ -11533,11 +11590,11 @@ msgstr "" "Cuando sea necesario probar una escena específica, pásala por línea de " "comandos." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "Depuración" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " @@ -11548,7 +11605,7 @@ msgstr "" "de comandos añadiendo ``-d``. Funciona tanto para ejecutar el juego como " "para una escena simple." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " @@ -11558,7 +11615,7 @@ msgstr "" "especialmente útil para configuraciones de integración continua. La versión " "de Godot que es headless (server build, no video) es ideal para esto." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -11571,7 +11628,7 @@ msgstr "" "intenta exportar a una plataforma no reconocida y se mostrará la lista " "completa de plataformas compatibles con tu configuración." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." @@ -11579,11 +11636,11 @@ msgstr "" "Para exportar una versión de depuración del juego, utiliza la opción ``--" "export-debug`` en lugar de ``--export``. Sus parámetros y uso son los mismos." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "Ejecutar un script" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " @@ -11593,19 +11650,19 @@ msgstr "" "función es especialmente útil en proyectos de gran envergadura, para la " "conversión por lotes de recursos o la importación/exportación personalizada." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "El script debe heredar de SceneTree o MainLoop." -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "He aquí un ejemplo simple de su funcionamiento:" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "Y cómo ejecutarlo:" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -15632,12 +15689,13 @@ msgid "Right-clicking the variable allows you to configure its properties:" msgstr "Clic derecho en la variable permite configurar sus propiedades:" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 +#, fuzzy msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" "Como puede verse, el tipo y valor iniciales e la variable pueden ser " "cambiados, así como algunos hints de propiedades. Seleccionando la opción " @@ -17043,7 +17101,7 @@ msgstr "get_scale()" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "Escala" @@ -17818,6 +17876,263 @@ msgstr "" "Si no se quiere que una carpeta sea importada in Godot, se puede hacer una " "excepción con un archivo .gdignore ." +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +#, fuzzy +msgid "Godot-Blender-Exporter" +msgstr "Importador de Escenas Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "Materiales" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +#, fuzzy +msgid "Export of Blender materials" +msgstr "Plantillas de exportación" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "No hay restricciones de uso para Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +#, fuzzy +msgid "Physics Properties" +msgstr "Propiedades de los nodos" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "By Type" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "Figuras de Colisión" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +#, fuzzy +msgid "There are the following caveats:" +msgstr "Tenemos entonces la siguiente tabla:" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +#, fuzzy +msgid "Collision Geometry Only" +msgstr "Detección de colisiones en 3D" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "Flujo de trabajo de los Assets" @@ -18951,10 +19266,29 @@ msgstr "" "exporter>`__ que hará un trabajo mucho mejor al exportar las escenas." #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 +#, fuzzy +msgid "Exporting ESCN files from Blender" +msgstr "Exportación de archivos DAE desde Blender" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 +msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 msgid "Import workflows" msgstr "Flujos de trabajo de importación" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" @@ -18963,7 +19297,7 @@ msgstr "" "respecto a cómo se importan los datos. Dependiendo de muchas opciones, es " "posible importar una escena con:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." @@ -18971,7 +19305,7 @@ msgstr "" "Materiales externos (por defecto): Donde cada material se guarda en un " "archivo de recursos. Se mantienen las modificaciones." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." @@ -18979,7 +19313,7 @@ msgstr "" "Mallas externas: Donde cada malla se guarda en un archivo diferente. Muchos " "usuarios prefieren trabajar con mallas directamente." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." @@ -18987,7 +19321,7 @@ msgstr "" "Animaciones externas: Permitir que las animaciones guardadas se modifiquen y " "combinen cuando cambien las fuentes." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." @@ -18995,11 +19329,11 @@ msgstr "" "Escenas externas: Guarda los nodos raíz de las escenas importadas, cada uno " "como una escena separada." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "Una sola escena: Un único archivo de escena con todo integrado." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." @@ -19007,23 +19341,23 @@ msgstr "" "Como los distintos desarrolladores tienen necesidades diferentes, este " "proceso de importación es altamente personalizable." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "Opciones de Importación" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "El importador tiene varias opciones, que se analizarán más adelante:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "Nodos:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "Tipos de Raíz" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." @@ -19031,19 +19365,19 @@ msgstr "" "Por defecto, el tipo de nodo raíz en las escenas importadas es \"Spatial\", " "pero puede modificarse." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "Nombre de la Raíz" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "Permite establecer un nombre específico para el nodo raíz generado." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "Script Personalizado" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " @@ -19053,11 +19387,11 @@ msgstr "" "después de la importación. Esto es ideal para post-procesamiento, cambio de " "materiales, hacer cosas divertidas con la geometría, etc." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "Crea un script como este:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " @@ -19067,14 +19401,14 @@ msgstr "" "parámetro es en realidad el nodo raíz de la escena). La escena que será " "utilizada debe ser devuelta. Puede ser una diferente." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "Almacenamiento" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " @@ -19084,7 +19418,7 @@ msgstr "" "que los nodos debajo de la raíz serán cada uno una escena separada e " "instanciada en la importada." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." @@ -19092,15 +19426,11 @@ msgstr "" "Por supuesto, instanciar estas escenas importadas en otros lados también " "funciona manualmente." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "Materiales" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "Localización" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." @@ -19108,7 +19438,7 @@ msgstr "" "Godot soporta materiales en mallas o nodos. Por defecto, los materiales se " "colocarán en cada nodo." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -19120,7 +19450,7 @@ msgstr "" "posible editarlos. Esto se debe a que la mayoría de los DCC 3D no tienen las " "mismas opciones de materiales que las presentes en Godot." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." @@ -19128,11 +19458,11 @@ msgstr "" "Cuando los materiales están integrados, se perderán cada vez que se " "modifique y se vuelva a importar la escena de origen." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "Continuar con la reimportación" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " @@ -19143,11 +19473,11 @@ msgstr "" "escena fuente. Esta opción sólo está presente si los materiales se guardan " "como archivos." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "Compresión" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." @@ -19155,11 +19485,11 @@ msgstr "" "Hace que las mallas utilicen números menos precisos para múltiples aspectos " "de la malla con el fin de ahorrar espacio." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "Estos son:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." @@ -19167,58 +19497,58 @@ msgstr "" "Matriz de Transformación (Ubicación, rotación y escala): flotante de 32 bits " "a entero con signo de 16 bits." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "Vértices: Flotante de 32 bits a un entero con signo de 16 bits." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "Normal: Flotante de 32 bits a un entero sin signo de 32 bits." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "Tangentes: Flotante de 32 bits a un entero sin signo de 32 bits." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" "Colores de vértices: Flotante de 32 bits a un entero sin signo de 32 bits." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "UV: Flotante de 32 bits a un entero sin signo de 32 bits." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "UV2: Flotante de 32 bits a un entero sin signo de 32 bits." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" "Pesos de los vértices: Flotante de 32 bits a un entero sin signo de 16 bits." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" "Huesos del armazón: Flotante de 32 bits a un entero sin signo de 16 bits." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." @@ -19226,18 +19556,18 @@ msgstr "" "Índice del array: entero sin signo de 32 o 16 bits en función de cuántos " "elementos contiene." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "Información adicional:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" "UV2 = El segundo canal UV para texturas de detalle y texturas lightmap " "preparadas." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." @@ -19245,7 +19575,7 @@ msgstr "" "Índice de array = Un array de números que numeran cada elemento de los " "arrays anteriores; es decir, numeran los vértices y normales." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -19260,15 +19590,15 @@ msgstr "" "discontinuidades en la geometría o en vértices movidos de donde deberían de " "estar." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "Modelos" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "Asegurar Tangentes" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -19280,7 +19610,7 @@ msgstr "" "en la escena de origen. Godot usa Mikktspace para esto, pero siempre es " "mejor tenerlos generados en el exportador." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " @@ -19290,7 +19620,7 @@ msgstr "" "integrados. Esto no tiene una gran utilidad a menos que uno quiera construir " "objetos con ellas directamente." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." @@ -19298,11 +19628,11 @@ msgstr "" "Esta opción se ofrece para ayudar a aquellos que prefieren trabajar " "directamente con mallas en lugar de escenas." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "Archivos Externos" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." @@ -19310,11 +19640,11 @@ msgstr "" "Las mallas y los materiales generados se pueden almacenar opcionalmente en " "un subdirectorio con el nombre de la escena." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "Opciones de animación" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -19327,15 +19657,15 @@ msgstr "" "animaciones en la misma línea de tiempo o, en el peor de los casos, poner " "cada animación en un archivo separado." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "La importación de animaciones está activada de forma predeterminada." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "FPS" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -19348,11 +19678,11 @@ msgstr "" "por segundo utilizados para editarlas. Si no se hace esto, el resultado " "puede ser una fluctuación mínima." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "Filtro de Script" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " @@ -19362,7 +19692,7 @@ msgstr "" "decidir qué pistas de qué animaciones se deben mantener. (@TODO necesita " "documentación)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " @@ -19372,11 +19702,11 @@ msgstr "" "posible guardarlas en un archivo. Esto permite añadir pistas personalizadas " "a las animaciones y mantenerlas después de una reimportación." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "Optimizador" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " @@ -19387,11 +19717,11 @@ msgstr "" "estar activado, a menos que sospeche que una animación puede estar rota " "debido a que está habilitado." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "Clips" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " @@ -19401,11 +19731,11 @@ msgstr "" "clips. Especifica de qué fotograma debe tomarse cada clip (y, por supuesto, " "no olvides especificar la opción FPS de arriba)." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "Herencia de Escenas" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -19417,7 +19747,7 @@ msgstr "" "cambia (archivo.dae, .gltf, .obj re-exportado desde la aplicación de " "modelado 3D), Godot reimportará toda la escena." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " @@ -19427,19 +19757,19 @@ msgstr "" "de Escenas*. Intenta abrir la escena importada y aparecerá el siguiente " "cuadro de diálogo:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" "En las escenas heredadas, las únicas limitaciones para las modificaciones " "son:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" "Los nodos no pueden ser eliminados (pero pueden ser agregados en cualquier " "parte)." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" @@ -19447,15 +19777,15 @@ msgstr "" "Los Sub-Recursos no pueden ser editados (guárdalos externamente como se " "describe arriba para este caso)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "Aparte de eso, ¡todo está permitido!" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "Consejos para la Importación" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" @@ -19463,15 +19793,15 @@ msgstr "" "Muchas veces, al editar una escena, hay tareas comunes que deben realizarse " "después de la exportación:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "Añadiendo detección de colisiones a los objetos:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "Configurar objetos como mallas de navegación" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" @@ -19479,7 +19809,7 @@ msgstr "" "Eliminar nodos que no se usan en el motor del juego (como luces específicas " "usadas para modelar)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " @@ -19489,11 +19819,11 @@ msgstr "" "pueden añadir a los nombres de los objetos en su software de modelado 3D. " "Cuando se importan, Godot los detecta y realiza acciones automáticamente:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "Eliminar nodos (-noimp)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." @@ -19502,11 +19832,11 @@ msgstr "" "la importación, independientemente de su tipo. No aparecerán en la escena " "importada." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "Crear colisiones (-col, -colonly, -convcolonly)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." @@ -19515,7 +19845,7 @@ msgstr "" "añadirá un nodo hijo de colisión estática, utilizando la misma geometría que " "la malla." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." @@ -19523,7 +19853,7 @@ msgstr "" "Sin embargo, a menudo se da el caso de que la geometría visual es demasiado " "compleja o irregular para las colisiones, que terminan por no funcionar bien." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " @@ -19533,7 +19863,7 @@ msgstr "" "malla al importarla y creará una colisión :ref:`class_staticbody` en su " "lugar. Esto ayuda a separar la malla visual de la colisión real." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." @@ -19541,7 +19871,7 @@ msgstr "" "La opción \"-convcolonly\" creará :ref:`class_convexpolygonshape` en lugar " "de :ref:`class_concavepolygonshape`." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -19553,23 +19883,23 @@ msgstr "" "colisión como hijo. El nodo de colisión tendrá una de las formas " "predefinidas, dependiendo del tipo de dibujo vacío del Blender:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "Flecha simple creará :ref:`class_rayshape`" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "Cubo creará :ref:`class_boxshape`" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "Imagen creará :ref:`class_planeshape`" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "Esfera (y otras no listadas) creará :ref:`class_sphereshape`" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " @@ -19580,11 +19910,11 @@ msgstr "" "color distinto para ellos en Preferencias de Usuario / Temas / Vista 3D / " "Vacío." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "Crear navigatopm (-navmesh)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." @@ -19592,11 +19922,11 @@ msgstr "" "Un nodo de malla con este sufijo se convertirá en una malla de navegación. " "Se eliminará el nodo Mesh original." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "Rigid Body (-rigid)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "Crea un rigid body a partir de esta malla." @@ -22046,8 +22376,9 @@ msgstr "" "del escenario." #: ../../docs/tutorials/2d/canvas_layers.rst:39 +#, fuzzy msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" "**HUD**: del inglés \"Head's up display\", referido a interfaces de usuario, " @@ -22072,14 +22403,15 @@ msgid "CanvasLayers" msgstr "CanvasLayers" #: ../../docs/tutorials/2d/canvas_layers.rst:49 +#, fuzzy msgid "" "The answer is :ref:`CanvasLayer `, which is a node that " "adds a separate 2D rendering layer for all its children and grand-children. " "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" "La respuesta es :ref:`CanvasLayer `, que es un nodo que " "añade una capa de renderizado 2D separada para todos sus hijos y nietos. Los " @@ -22132,8 +22464,9 @@ msgid "Viewport and canvas transforms" msgstr "Transformación de Viewport y Canvas" #: ../../docs/tutorials/2d/2d_transforms.rst:9 +#, fuzzy msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -22193,10 +22526,11 @@ msgid "Stretch transform" msgstr "Stretch transform" #: ../../docs/tutorials/2d/2d_transforms.rst:39 +#, fuzzy msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" "Por último, las ventanas de visualización tienen un *Stretch Transform*, que " @@ -22206,11 +22540,12 @@ msgstr "" "cada viewport." #: ../../docs/tutorials/2d/2d_transforms.rst:44 +#, fuzzy msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" "Eventos de entrada (Input events) recibidos en el callback de :ref:`MainLoop." @@ -22320,8 +22655,9 @@ msgstr "" "`" #: ../../docs/tutorials/2d/2d_transforms.rst:73 +#, fuzzy msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" "Finalmente, para convertir un un CanvasItem de coordenadas locales a " @@ -22502,8 +22838,9 @@ msgstr "" "de editar." #: ../../docs/tutorials/2d/using_tilemaps.rst:83 +#, fuzzy msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -22697,9 +23034,10 @@ msgstr "" "configurándola como ``current`` y probando con el ``zoom``." #: ../../docs/tutorials/2d/using_tilemaps.rst:182 +#, fuzzy msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" "Puedes utilizar una imagen para cada tile. Esto eliminará todos los " "artefactos pero puede ser complicado de implementar y es menos óptimo." @@ -22714,9 +23052,10 @@ msgid "Why?" msgstr "¿Por qué?" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 +#, fuzzy msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -22844,12 +23183,13 @@ msgid "An example: drawing circular arcs" msgstr "Un ejemplo: dibujando arcos de curva" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:149 +#, fuzzy msgid "" "We will now use the custom drawing functionality of the Godot Engine to draw " "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." +"perform this and draw it yourself." msgstr "" "Ahora veremos el uso de la funcionalidad de dibujo personalizado de Godot " "Engine para dibujar algo para lo que el motor no provee ninguna función. Por " @@ -22857,17 +23197,18 @@ msgstr "" "completo, pero ¿y si queremos dibujar una porción de un círculo? Deberás " "crear una función para hacer eso y dibujarlo." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 msgid "Arc function" msgstr "Función arco" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 +#, fuzzy msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" "Un arco está depende de los parámetros de un círculo de soporte, es decir, " "posición central y radio. El arco en sí es definido por el ángulo en el que " @@ -22875,18 +23216,19 @@ msgstr "" "pasamos a nuestro dibujo. Podemos también agregar un valor de color para " "dibujar el arco en diferentes colores." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 +#, fuzzy msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" "Básicamente, dibujar una figura requiere descomponerla en cierto número de " "puntos, vinculados uno al otro. Como puedes imaginar, mientras más puntos " @@ -22898,7 +23240,7 @@ msgstr "" "inglés). En nuestro ejemplo usaremos un número fijo de puntos, sin importar " "el radio." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " @@ -22908,7 +23250,7 @@ msgstr "" "Fijamos este número en la variable nb_points a un valor de 32, luego " "inicializamos un PoolVector2Array vacío, que es un arreglo de Vector2." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -22922,14 +23264,15 @@ msgstr "" "uno para incluir el último punto. Primero determinamos el ángulo de cada " "punto, entre el ángulo inicial y el ángulo final." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 +#, fuzzy msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" "La razón por la que reducimos cada ángulo en 90° es porque computamos " "posiciones de cada ángulo utilizando trigonometría. cos() y sin() utilizan " @@ -22937,7 +23280,7 @@ msgstr "" "hacia la derecha, pero queremos que comience apuntando hacia arriba. Así que " "reducimos el ángulo en 90° para conseguirlo." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -22958,7 +23301,7 @@ msgstr "" "Vector2. Finalmente insertamos el punto en e PoolVector2Array que fue " "definido previamente." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -22978,27 +23321,28 @@ msgstr "" "entre cada par de puntos nunca será lo suficientemente larga para verlos. Si " "esto sucede, simplemente aumentamos el número de puntos." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "Dibujar el arco en pantalla" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#, fuzzy msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" "Ahora tenemos una función que dibuja cosas en la pantalla: es momento de " "llamar la función _draw()." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "Resultado:" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "Función de polígono arco" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -23010,17 +23354,18 @@ msgstr "" "El método es exactamente el mismo que el anterior, excepto que dibujamos un " "polígono en lugar de líneas:" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "Dibujos personalizados dinámicos" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 +#, fuzzy msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" "Ahora somos capaces de dibujar figuras personalizadas en pantalla, sin " "embargo, son estáticas. Hagamos que la figura gire en torno al centro. La " @@ -23029,7 +23374,7 @@ msgstr "" "50, este valor de incremento deberá permanecer constante sino la velocidad " "de rotación cambiará de acuerdo a las modificaciones." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " @@ -23040,20 +23385,21 @@ msgstr "" "del script. También se pueden colocar en otros nodos y accederlas mediante " "``get_node(\"nombre_nodo\").nombre_variable``." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "Haremos que esos valores cambien en la función _process(delta)." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 +#, fuzzy msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" "También incrementaremos nuestros valores angle_from y angle_to aquí. Sin " "embargo no debemos olvidar de aplicar ajuste en el valor resultante para " @@ -23063,7 +23409,7 @@ msgstr "" "programa puede cerrarse o realizar un comportamiento no esperado. Como Godot " "no provee una función así, la crearemos aquí, es relativamente simple." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " @@ -23073,7 +23419,7 @@ msgstr "" "una llamada a _draw(). de este modo, podrás controlar cuando quieres que se " "actualice." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" @@ -23081,14 +23427,14 @@ msgstr "" "Y no olvides modificar la función _draw() para que haga uso de estas " "variables:" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" "Ejecutémoslo y veamos como funciona. Podemos notar que el arco rota " "demasiado rápido, qué está mal?" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -23107,7 +23453,7 @@ msgstr "" "asegurar que el programa se ejecutará a la misma velocidad en todo tipo de " "hardware." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " @@ -23118,25 +23464,26 @@ msgstr "" "incrementarán por un valor muy bajo, dependiendo directamente de nuestra " "velocidad de procesamiento." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "¡Ejecutémoslo de nuevo! ¡Esta vez, la rotación se muestra bien!" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Tools" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 +#, fuzzy msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" "Dibujar tus propios nodos puede ser deseable mientras se ejecutan en el " "editor, para usarlo como previsualización de alguna característica o " "comportamiento." -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -23286,10 +23633,11 @@ msgid "Speed Scale" msgstr "Speed Scale (Escala de Velocidad)" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 +#, fuzzy msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" "La escala de velocidad tiene un valor predeterminado de ``1``, y se usa para " "ajustar la velocidad de un sistema de partículas. Disminuir el valor hará " @@ -23301,9 +23649,10 @@ msgid "Explosiveness" msgstr "Explosiveness (Explosividad)" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 +#, fuzzy msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" "Si el tiempo de vida es ``1`` y hay diez partículas, significa que se " @@ -23593,9 +23942,10 @@ msgid "Hue variation" msgstr "Hue variation (Variación de tono)" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 +#, fuzzy msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" "El valor de variación establece la variación de tono inicial aplicada a cada " "partícula. El valor de rand de la variación controla la relación de " @@ -23954,9 +24304,10 @@ msgid "Generated geometry" msgstr "Geometría generada" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 +#, fuzzy msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -24027,7 +24378,7 @@ msgstr "" "trabajo en píxeles." #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "Entorno" @@ -24200,7 +24551,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -24233,10 +24584,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -24669,16 +25016,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -24721,6 +25068,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -25044,8 +25392,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -25059,14 +25407,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -25098,67 +25446,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -25167,334 +25515,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -25502,11 +25850,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -25515,30 +25863,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -25546,11 +25894,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -25560,11 +25908,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Profundidad" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -25573,66 +25921,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -25640,38 +25988,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -25682,13 +26030,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -25731,8 +26079,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -25743,7 +26091,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -25771,56 +26119,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -25828,26 +26176,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -25855,23 +26203,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -25880,129 +26228,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -26010,111 +26357,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -26144,61 +26491,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -26206,7 +26554,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -26214,42 +26562,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -26257,31 +26605,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -26296,186 +26644,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -26489,38 +26837,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -26529,44 +26877,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "Desplegar desde de su 3D DCC" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "Simplemente despliegue la segunda capa UV2." -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -26574,11 +26922,11 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "Desplegar desde Godot" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" @@ -26586,17 +26934,17 @@ msgstr "" "Godot tiene la opción de desplegar mallas y visualizar los canales UV. Se " "puede encontrar en el menú Malla:" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "Desplegar en la Importación de la Escena" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -26609,7 +26957,7 @@ msgstr "" "Sistema de Archivos, luego ve a la pestaña Importar. Allí se puede modificar " "la siguiente opción:" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -26617,13 +26965,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -26632,113 +26980,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -26746,110 +27094,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -26857,12 +27205,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -26875,213 +27223,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -27089,38 +27437,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -27130,90 +27478,90 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." @@ -27221,60 +27569,60 @@ msgstr "" "** Fundido de salida** permite ajustar la curva de fundido de salida, de " "modo que el límite de paso se fundirá suavemente." -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -27282,143 +27630,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -27426,78 +27775,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -27538,10 +27887,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -27593,11 +27942,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -27633,7 +27982,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -27644,8 +27993,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -27660,23 +28009,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -27687,7 +28037,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -27904,9 +28254,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -27914,46 +28264,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -27961,92 +28312,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" "Para modificar el resultado, repite el mismo paso con parámetros diferentes." @@ -28069,28 +28419,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -28099,7 +28448,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -28110,7 +28459,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -28120,50 +28469,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -28171,137 +28520,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -28309,31 +28667,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -28347,45 +28705,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -28393,68 +28756,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -28462,14 +28825,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -28482,8 +28845,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -28527,7 +28890,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -36126,14 +36489,14 @@ msgid "Audio" msgstr "Audio" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -36153,40 +36516,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -36194,37 +36561,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -36232,7 +36599,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -36242,79 +36609,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -36322,7 +36687,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -36334,39 +36699,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -36375,11 +36740,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -36387,53 +36752,53 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" "Este es un simple helper para ajustar el sonido a la izquierda o a la " "derecha." -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -36441,55 +36806,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -36498,11 +36863,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -36817,10 +37182,6 @@ msgstr "" "Es un cuerpo que provee detección de colisiones, pero no física. Todo " "movimiento y respuestas a colisiones debe ser implementado en código." -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "Figuras de Colisión" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -39314,2425 +39675,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "Así que el algoritmo final es algo así como:" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "Rotaciones" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" -"En el contexto de las transformaciones 3D, las rotaciones son la parte no " -"trivial y complicada. Mientras que es posible describir rotaciones 3D usando " -"dibujos geométricos y derivar las matrices de rotación, que es con lo que la " -"mayoría de la gente estaría más familiarizada, ofrece una imagen limitada, y " -"no da ninguna idea de las cosas prácticas relacionadas tales como " -"cuaterniones y SLERP. Por esta razón, este documento adopta un enfoque " -"diferente, un enfoque general (aunque un poco abstracto al principio) que " -"fue popularizado por su uso extensivo en las teorías de los indicadores " -"locales en física. Dicho esto, el objetivo de este texto es proporcionar una " -"base mínima para entender las rotaciones 2D y 3D de una manera general y " -"arrojar luz sobre cosas prácticas como el bloqueo del cardán, los " -"cuaterniones y SLERP utilizando un lenguaje accesible para los " -"programadores, y no la integridad o el rigor matemático." - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "Un curso intensivo en grupos de Lie y álgebra para programadores" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" -"Los grupos de Lie son una rama de las matemáticas que se ocupa de las " -"rotaciones de manera sistemática. Aunque es un tema extenso y la mayoría de " -"los programadores ni siquiera han oído hablar de él, es relevante en el " -"desarrollo de juegos, porque proporciona una visión coherente y unificada de " -"las rotaciones 3D." - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" -"Así que empecemos con pequeños pasos. Imaginemos que queremos hacer una " -"pequeña rotación alrededor de algún eje. Para concretar, digamos alrededor " -"del eje :math:`z` por un ángulo infinitesimal `:math:`\\delta\\theta`. Para " -"ángulos pequeños, como se ilustra en la figura, el operador de rotación " -"puede escribirse como :math:`R_z(\\delta\\theta) = I + \\delta \\theta " -"\\boldsymbol e_z \\times`donde :math:`I` es operador de identidad y :math:`" -"\\boldsymbol e_z` es un vector unitario a lo largo del eje :math:`z`, de " -"manera que un vector :math:`\\boldsymbol v` se convierte en" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" -"(Si esto no está claro, puedes verificar esto mirando la figura: :math:`" -"\\boldsymbol v` es rotado dentro de :math:`\\boldsymbol v'` en el plano (así " -"que el eje de rotación :math:`\\boldsymbol e_z` está apuntando fuera de la " -"pantalla). La superposición de dos vectores es :math:`\\boldsymbol v \\cdot " -"\\boldsymbol v' = v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta" -"\\theta^2)` ya que la rotación es muy reducida, así que la parte de :math:`" -"\\boldsymbol v'`paralela a :math:`\\boldsymbol v` es en realidad :math:`" -"\\boldsymbol v`. Aquí,:math:`v = |\\boldsymbol v|`. ¿Qué hay de la parte " -"perpendicular, que debe ser :math:`\\boldsymbol v' - \\boldsymbol v`? Usando " -"la regla de la mano derecha, la dirección es :math:`\\boldsymbol e_z \\times " -"\\boldsymbol v/v`, y de primer orden en :math:`\\delta\\theta`, podemos " -"aproximar la longitud del vector de diferencia por la longitud del arco " -"(arco azul en la figura) que es :math:`\\delta \\theta v` así que el " -"componente perpendicular :math:`\\delta \\theta \\boldsymbol e_z \\times " -"\\boldsymbol v` también es comprobado.)" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" -"Ahora, una forma práctica de representar operadores es usando matrices (note " -"que un `operador `_ no " -"es una matriz, y hay diferentes objetos matemáticos aparte de las matrices " -"que se usan para representar operadores, tales como cuaterniones, un punto " -"al cual volveremos más tarde cuando estemos discutiendo `representaciones " -"``_. En términos de " -"matrices reales de :matemáticas:`3 \\por 3`, el operador de identidad :math:" -"`I` simplemente corresponde a un :math:`3 \\times 3` matriz de identidad, y " -"el producto cruzado :math:`\\boldsymbol e_z \\times` puede representarse como" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" -"(Si tienes curiosidad por saber cómo encontrar la representación matricial " -"de un operador :math:`A` en algún tipo de base real :math:`\\{ \\boldsymbol " -"e_i\\}`: el elemento matriz en :math:`i` fila anterior :math:`j` esta " -"columna viene dada por :math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; " -"la base que usamos aquí es :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, " -"\\boldsymbol e_z \\}`) No es casualidad que :math:`J_z` rotará un vector en " -"el plano :math:`xy` alrededor del eje :math:`z` por :math:`\\pi/2`; para un " -"eje arbitrario :math:`\\boldsymbol n` el operador :math:`J_n \\cong " -"\\boldsymbol n \\times` es rotado por :math:`\\pi/2` alrededor de ese eje " -"para vectores en el plano perpendicular a :math:`\\boldsymbol n`." - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" -"En términos de :math:`J_z`, podemos expresar el operador de rotación " -"infinitesimal alrededor del eje :math:`z` como" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" -"Entonces, ¿qué tal rotaciones finitas? Simplemente podemos aplicar este " -"operador de rotación infinitesimal :math:`N` veces para obtener una rotación " -"finita :math:`\\theta \\equiv N \\delta \\theta`:" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" -"(Si estás confundido acerca de ver una matriz como un exponente: el " -"significado de un operador :math:`A` en un `mapa exponencial `_ está dado por la " -"expansión de su serie como :math:`e^A = 1 + A + A^2/2! + \\ldots` ). Esta es " -"posiblemente la relación más importante en este artículo, y se sitúa en el " -"corazón de los grupos de Mentiras, cuyo significado será aclarado " -"próximamente. Pero primero, demos un paso atrás y observemos el significado " -"de este resultado: usando una simple imagen de una rotación infinitesimal, " -"derivamos una expresión general para rotaciones arbitrarias alrededor del " -"eje :math:`z`. De hecho, esto se pone aún mejor. Si hubiéramos repetido el " -"mismo análisis para rotaciones alrededor de los ejes :math:`x` y :math:`y`, " -"habríamos obtenido resultados similares a :math:`e^{\\theta J_y}` y :math:" -"`e^{\\theta J_y}` respectivamente, donde" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" -"O, si hubiéramos hecho una rotación alrededor de un eje arbitrario :math:`" -"\\boldsymbol n`, el resultado habría sido" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" -"donde :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Observa cómo el eje de " -"rotación :math:`\\boldsymbol n` y el ángulo de rotación :math:`\\theta` " -"juegan un papel central en la expresión final. Eje-ángulo es *la* " -"parametrización para *todos* los grupos de Lie, no sólo las rotaciones 3D. " -"(Volveremos a este punto más adelante cuando discutamos la parametrización " -"del ángulo de Euler, que es una parametrización antinatural y defectuosa de " -"las rotaciones en 3D.)" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" -"Si alguna vez has intentado derivar la matriz de rotación correspondiente a " -"una rotación :math:`\\theta` alrededor de :math:`\\boldsymbol n`, puedes " -"apreciar la simplicidad y elegancia de cómo obtuvimos este resultado. Para " -"ser justos, todavía necesitamos averiguar cómo usar un operador situado " -"encima de un exponente (resumiendo la serie de Taylor), por supuesto, pero " -"eso es meramente una labor \"programática\" y sólo necesitamos seguir la " -"tabla de multiplicación finita de operadores :math:`J_i`. Pero esto es mucho " -"más sencillo que tratar de dibujar diagramas geométricos y ángulos y " -"calcular la matriz de rotación. Para el caso particular del álgebra " -"correspondiente a las rotaciones en el espacio Euclídeo 3D del que hemos " -"estado hablando hasta ahora, el exponente puede escribirse simplemente como" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" -"que se conoce como la fórmula de rotación de Rodrigues. Nótese que sólo " -"terminamos con términos de segundo orden en :math:`\\boldsymbol n \\cdot " -"\\boldsymbol J` cuando sumamos la expansión de la serie; la razón es que las " -"potencias superiores pueden ser reducidas a términos de 0º, 1er o 2º orden " -"debido a la relación :math:`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -" -"\\boldsymbol n \\cdot \\boldsymbol J`, lo que hace que resumir la serie sea " -"sencillo." - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" -"Lo que se encuentra encima de los operadores :math:`e`, que es una " -"combinación lineal :math:`J_i` (donde :math:`i = x,y,z`), forma un álgebra; " -"de hecho, forma un espacio vectorial cuyos \"vectores\" base son :math:" -"`J_i`. Además, el álgebra se cierra bajo el corchete de Lie (que es " -"esencialmente un conmutador: :math:`[a,b] = a b - ba`, y es algo así como un " -"producto cruzado en este espacio vectorial). En el caso particular de las " -"rotaciones 3D, esta \"tabla de multiplicación\" es :math:`[J_x, J_y] = J_z` " -"and its cyclic permutations :math:`x\\to y, y\\to z, z\\to x`." - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" -"Las rotaciones forman lo que se llama un `grupo `_: en pocas palabras, significa que si " -"combinas dos rotaciones, obtienes otra rotación. Y puedes observarlo aquí " -"también: cuando pones un elemento del álgebra de Lie (que son simplemente " -"combinaciones lineales de :math:`J_i`) encima de :math:`e`, obtienes lo que " -"se llama un grupo de Lie, y se dice que el álgebra de Lie *genera* el grupo " -"de Lie. Por ejemplo, se dice que el operador :math:`J_z \\equiv \\boldsymbol " -"e_z \\times` *genera* las rotaciones alrededor del eje `z`. El grupo de " -"rotaciones en el espacio euclídeo 3D se llama SO(3)." - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" -"El orden de rotaciones en 2D no importa: primero puedes rotar por :math:`" -"\\pi` y rotar por :math:`\\pi/2`, o hacerlo en orden inverso, y de cualquier " -"manera, el resultado es una rotación por :math:`3 \\pi/2` en el plano. Pero " -"el orden de las rotaciones en 3D importa, en general, cuando se trata de " -"diferentes ejes de rotación (ver `esta imagen `_ para un ejemplo) (las rotaciones alrededor de los mismos " -"ejes viajan, por supuesto). Cuando el orden de los elementos del grupo no " -"importa, se dice que ese grupo es abeliano, y de otra manera no abeliano. " -"SO(2) es un grupo abeliano, y SO(3) es un grupo no-abeliano." - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" -"Los grupos de Lie y las algebras *no* son matrices. Se pueden *representar* " -"ambos usando objetos que emulen sus reglas de \"multiplicación\": pueden ser " -"matrices reales o complejas de dimensiones variables, o algo así como " -"cuaterniones. Un solo grupo de Lie/álgebra tiene infinitamente muchas " -"representaciones diferentes en espacios vectoriales de diferentes " -"dimensiones (ver `esto `_ por ejemplo para SO(3)). " -"Arriba, utilizamos la representación real 3D de SO(3), que resulta ser la " -"representación fundamental, y coincide accidentalmente con la representación " -"adjunta." - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "Algunos comentarios matemáticos (siéntete libre de omitirlos)" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" -"Hay muchos grupos de Lie diferentes, que corresponden a diferentes " -"simetrías, y todos tienen diferentes nombres. Por ejemplo, el grupo que " -"contiene todas las rotaciones en el espacio euclidiano :math:`n`-dimensional " -"se llama SO(:math:`n`), y tiene :math:`n (n-1)/2` generadores linealmente " -"independientes (sí, los grupos de Lie pueden manejar rotaciones de " -"dimensiones más altas tal cual, e incluso en los no euclidianos). Esto se " -"llama el *rango* del álgebra de Lie. Se puede pensar en los generadores como " -"ejes de rotación independientes. Para 2D, sólo podemos rotar en el plano :" -"math:`xy` lo que significa que sólo tenemos 1 generador. Para 3D, se puede " -"rotar alrededor de 3 planos/ejes diferentes." - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" -"Los grupos de Lie tienen profundas conexiones con las simetrías y han jugado " -"un papel central en la física teórica desde mediados del siglo XX." - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" -"Por ejemplo, si algo es simétrico bajo rotación 3D, ese algo (en física, es " -"típicamente lagrangiano, lo que lleva a las leyes de conservación a través " -"del teorema de Noether) permanece invariable bajo las transformaciones SO(3) " -"(cubriremos las transformaciones a continuación)." - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" -"En el contexto de los grupos de Lie y la teoría de grupos en general, " -"algunas palabras comunes tienen significados específicos y una parte de la " -"jerga matemática: representación, generador, grupo, álgebra, " -"parametrización, operador son tales palabras. No es necesario que conozcas " -"sus definiciones precisas para entender esta redacción; sólo ten en cuenta " -"que son términos especiales y pueden no significar lo que crees que " -"significan. Todos estos términos se describen en este artículo en un " -"lenguaje coloquial." - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "Representación de rotaciones" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" -"La representación de rotaciones es un concepto independiente de la " -"parametrización de rotaciones. Estos dos conceptos son comúnmente mezclados, " -"lo que lleva al estado actual de confusión entre muchos programadores. La " -"gente tiende a asociar la parametrización de los ángulos de Euler con " -"matrices (¡o a veces incluso con vectores!), y la parametrización del eje-" -"ángulo con cuaterniones." - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" -"En los motores de juego, los operadores de rotación se representan " -"utilizando matrices o cuaterniones. Desafortunadamente, incluso los libros " -"de programación de gráficos y las documentaciones de motores de juego caros " -"a menudo cometen un error aquí, y esto hace que los programadores comiencen " -"a comparar los ángulos de Euler (una parametrización) con los cuaterniones " -"(una representación) e incluso a discutir sus equilibrios, lo que \"ni " -"siquiera es incorrecto\"." - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" -"`Representación de grupo `_ aquí se refiere a un término técnico de la teoría de " -"grupos. Así como muchas otras cosas que se mencionarán en lo que sigue. Para " -"obtener una comprensión básica de estos conceptos, primero pasemos a través " -"de ejemplos más simples y mejor entendidos de rotaciones en 2D." - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "Representación de rotaciones en 2D" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" -"Dado que sólo hay un eje de rotación posible en un plano bidimensional, no " -"hay parametrización del ángulo de Euler para ellos (o si lo prefieres, sólo " -"hay un ángulo de Euler). En su lugar, se utiliza la parametrización eje-" -"ángulo, fijando el eje al eje z, lo que deja sólo el ángulo de rotación :" -"math:`\\varphi` como parámetro libre." - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" -"Un punto en el espacio 2D euclidiano puede ser representado por un par de " -"números reales 2D como :math:`\\boldsymbol v = (x,y)` (llamado " -"representación vectorial), o alternativamente pueden ser representados por " -"un número complejo como :math:`v = x + \\imath y` donde :math:`\\imath " -"\\equiv \\sqrt{-1}` es un número imaginario de la unidad. En la " -"representación vectorial, podemos rotar el punto a través de una matriz de " -"rotación (un elemento del grupo Lie SO(2), el cual puede ser representado " -"por matrices ortogonales :math:`2 \\times 2` con determinante +1) como sigue:" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" -"Así, por ejemplo, cuando :math:`\\theta=\\pi/2`, obtenemos :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" -"En la representación compleja, una rotación está representada por un número " -"complejo de unidades :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin" -"\\theta`, donde usamos la `fórmula de Euler `_, es un elemento del grupo de Lie U(1), que puede ser " -"representado por números complejos de la norma unitaria. Una vez más, para :" -"math:`\\theta=\\pi/2`, recuperas :math:`e^{\\imath\\pi/2}(x+\\imath y) = " -"\\imath(x+\\imath y) = (-y) + \\imath x`." - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" -"Las rotaciones en la representación de números complejos parecen más " -"simples, pero es sólo una ilusión: las complicaciones de realizar una " -"multiplicación matricial son absorbidas por la introducción de algo que vive " -"fuera del reino de los números reales, que sigue a un álgebra bastante " -"\"extraña\": :math:`\\imath^2 = -1`. La manera en que los números complejos " -"imitan las rotaciones 2D puede ser más clara si reescribimos la matriz de " -"rotación en términos de" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" -"que puede ser comparada con :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin" -"\\theta`directamente. Ahora podemos ver la equivalencia (el término técnico " -"es `isomorfismo `_ en este " -"contexto) de las representaciones más claras a través de su tabla de " -"multiplicación: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z I_2 = J_z, J_z J_z " -"= -I_2` lo cual se comporta de la misma manera que :math:`1 \\times 1 = 1, 1 " -"\\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath \\times " -"\\imath = -1`. También ten en cuenta que tanto :math:`\\imath` como :math:" -"`J_z` representan una rotación de :math:`\\pi/2`. Y como debe ser, :math:`" -"\\imath` and :math:`J_z` se comportan igual en la multiplicación." - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" -"Además, mediante la expansión de la serie de Taylor, es sencillo mostrar " -"que :math:`R(\\theta) = e^{J_z \\theta}`." - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "Tenemos entonces la siguiente tabla:" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "Lo que" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "Representación de la matriz de SO(2)" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "Representación compleja de U(1)" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "Vector" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr ":math:`(x,y)`" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr ":math:`x+\\imath y`" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "Generador" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr ":math:`J_z \\cong \\imath`" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "Operador de rotación" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" -"Claramente, la introducción del número imaginario unitario es suficiente " -"para capturar el comportamiento de las matrices de rotación 2D. Como nota al " -"pie de página, mientras que el número :math:`e^{{imath{theta}` sólo puede " -"representar una matriz de rotación, por supuesto no puede representar una " -"matriz arbitraria :math:`2 \\times 2` (lo que significa que no hay escalado, " -"roturas, etc): después de todo, U(1) no es isomorfo para `:math:`\\text{GL}" -"(2, \\mathbb R)`, el grupo de todas las matrices reales (invertibles) de :" -"math:`2\\times 2`." - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" -"La equivalencia de estas dos formas aparentemente diferentes de representar " -"vectores y rotaciones en 2D radica en el `isomorfismo entre los grupos de " -"Lie SO(2) y U(1) `_." - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" -"Además, en esta representación, está claro que se puede hacer una rotación " -"\"suave\" cambiando lentamente :math:`\\theta`, que es el análogo 2D de " -"SLERP (¡también podría llamarse Interpolación Lineal Circular!). Si se " -"interpolan linealmente los *elementos* de dos matrices de rotación (es " -"decir, interpolando linealmente entre :math:`R_{ij}` y :math:`R'_{ij}` ), se " -"obtendrá una trayectoria extraña con un movimiento espasmódico; para hacer " -"SLERP con una matriz, es necesario extraer los ángulos de cada matriz (lo " -"que sólo puede ocurrir para matrices cuyas entradas tienen que formarse por :" -"math:`R(\\theta)` arriba; es decir, elementos de SO(2)), interpolar entre " -"los ángulos linealmente, y construir la matriz intermedia usando ese ángulo." - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" -"Las ventajas más comprensibles de esta breve visita a la tierra 2D son:" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" -"Puede haber diferentes (pero \"equivalentes\", por supuesto) " -"*representaciones* de rotaciones: como matrices y números complejos." - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" -"A pesar de que se pueden usar números complejos para representar vectores y " -"rotaciones en 2D, el *concepto* de rotaciones en 2D no requiere un " -"entendimiento/conocimiento de números complejos o de la fórmula de Euler." - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" -"La introducción del imaginario :math:`\\imath` no es magia negra: es algo " -"que se imita a la matriz de :math:`2 \\times 2` :math:`J_z`: `math:`1` y :" -"math:`\\imath` se comportan de la misma manera que :math:`I_2` and :math:" -"`J_z` en la multiplicación (ver la tabla de multiplicación de grupos " -"mostrada más arriba)." - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" -"Éstas son a menudo fuentes de confusión en 3D: introducir una tercera " -"dimensión significa que tenemos nuevos ejes de rotación (rotaciones " -"alrededor de los ejes X e Y) dando lugar a parametrizaciones alternativas " -"(como los ángulos de Euler), y nuevos generadores :math:`J_x` y `mateh:" -"`J_y`, que será la generalización de :math:`J_z` arriba." - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" -"Algunos comentarios matemáticos (de nuevo, siéntete libre de omitirlos)" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" -"El hecho de que SO(3) tenga 3 generadores es un accidente: SO(:math:`n`) " -"tiene :math:`n(n-1)/2` generadores. Además, el siguiente paso (después de " -"los cuaternios, que es `otro accidente `_) de `construcción de Cayley-Dickson " -"`_ no " -"corresponde a un álgebra Lie, sino a un álgebra no asociativa llamada " -"`octonions `_. Más bien, en " -"dimensiones arbitrarias, la representación \"compleja\" puede ser escrita " -"usando los generadores de Spin(:math:`n`), que es una doble portada de SO(:" -"math:`n`). Además, a lo largo de esta página, cuando decimos representación " -"de SO(2), U(1) o cualquier otro grupo, estamos hablando de la `*fundamental* " -"`_ `representación " -"irreductible `_, " -"correspondiente a un `Diagrama joven `_ con una sola casilla." - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "Representación de rotaciones en 3D" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" -"Primero repasemos cómo funcionan las rotaciones 3D usando vectores y " -"matrices ya conocidos." - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" -"En 2D, consideramos vectores que yacen en el plano :math:`xy`, y el único " -"eje que podíamos rotarlos era el eje :math:`z`. En 3D, podemos realizar una " -"rotación alrededor de cualquier eje. Y esto no sólo significa alrededor de " -"los ejes `x, y, z`, la rotación también puede ser alrededor de un eje que es " -"una combinación lineal de ellos, donde :math:`\\boldsymbol n` es el vector " -"unitario (es decir, :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) " -"alineado con el eje que queremos realizar la rotación." - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" -"Al igual que la matriz de rotación 2D, la matriz de rotación 3D también " -"puede ser derivada con un poco de esfuerzo dibujando muchas flechas y " -"ángulos y algo de álgebra lineal, pero esto sería opaco y no nos dará mucha " -"información de lo que está pasando. Una forma menos directa, pero más " -"gratificante de derivar esta matriz es entender el grupo de rotación SO(3)." - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" -"SO(3) es el grupo de rotaciones en el espacio 3D euclidiano (cuya `firma " -"`_ es :math:`(+1,+1,+1)`), " -"que conservan la magnitud y procedencia de los vectores sobre los que actúa. " -"La forma más típica de representar sus elementos es usar matrices " -"ortogonales reales de :math:`3 \\times 3` con determinante :math:`+1`. Esta " -"representación se llama la representación fundamental de SO(3)." - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" -"Para recapitular lo que hablamos antes, SO(3) tiene 3 generadores, :math:" -"`J_x, J_y, J_z` y encontramos que pueden ser representados usando las " -"siguientes :math:`3\\times 3` matrices reales:" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" -"Estos matrices tienen la misma \"tabla de multiplicación\" que :math:`J_i` " -"(son isomórficos), así que para todos los efectos prácticos, puede " -"reemplazar los operadores con sus representaciones matriciales." - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" -"También encontramos que un elemento de SO(3), es decir, un operador de " -"rotación es" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" -"Si quieres, puedes conectar las representaciones de la matriz para :math:" -"`J_i` y derivar la complicada matriz de rotación :math:`3\\times 3 que es" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" -"(Pista: puedes usar la relación :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` para evaluar rápidamente el " -"último término de la fórmula de Rodrigues, donde :math:`\\otimes` es el " -"`producto de Kronecker `_ que también se llama `producto exterior `_ " -"para reescribir :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` y :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}{2}" -"` en la fórmula de Rodrigues, se pueden usar términos de coseno y seno como " -"una ayuda visual cuando se compara con la forma de la matriz.)" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" -"Sin embargo, no *tenemos que* usar matrices para representar generadores " -"SO(3) :math:`J_i`. ¿Recuerdas cómo usamos :math:`\\imath`, la unidad " -"imaginaria para emular :math:`J_z` en lugar de usar una matriz :math:`2 " -"\\times 2`? Resulta que podemos hacer algo similar aquí." - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" -"`Hamilton `_ es " -"comúnmente conocido por la omnipresente `mecánica Hamiltoniana `_ en física. Una de sus " -"contribuciones menos conocidas es esencialmente una forma alternativa de " -"representar el producto vectorial 3D, que finalmente cedió a la popularidad " -"del vector habitual `productovectorial `_. Esencialmente se dio cuenta de que hay tres " -"rotaciones diferentes no conmutadas en 3D, y le dio un nombre al generador " -"para cada una. Identificó a los operadores :math:`\\{\\boldsymbol e_x " -"\\times, \\boldsymbol e_y \\times, \\boldsymbol e_z \\times\\}` como los " -"elementos de un álgebra, nombrándolos :math:`\\{i,j,k\\}`." - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" -"Esto puede sonar trivial en este punto, porque estamos equipados con toda la " -"maquinaria de los grupos y algebras de Lie: aparentemente, las unidades de " -"cuaterniones :math:`\\{i,j,k\\}` son sólo otra representación de los " -"generadores de SO(3), que satisfacen el soporte de Lie. Bueno, no tan " -"rápido. Mientras que el *álgebra* de la Lie :math:`\\mathfrak{so}(3)`, cuyos " -"elementos son la combinación lineal de :math:`J_i` s son isomórficos a los " -"cuaterniones unitarios, pero los cuaterniones son :math:`1 w + x i + y j + z " -"k` en general, así que también hay una parte de identidad, que no es un " -"vector que es parte de cualquier álgebra de Lie. Las cuartniones se parecen " -"más al *grupo* SO(3) (cuando están normalizados, porque el SO(3) preserva " -"las normas vectoriales). Pero en realidad no es isomorfo al SO(3). Resulta " -"que los cuaterniones unitarios son isomórficos al grupo SU(2) (que es " -"isomórfico a Spin(3)), que a su vez es una doble cobertura de SO(3)." - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" -"SU(2) es esencialmente el grupo de rotaciones unitarias con determinante +1 " -"(llamados grupos unitarios especiales) que preservan la norma de los " -"vectores complejos sobre los que actúa, generados por `Matrices de Pauli " -"`_ :math:`\\sigma_i` y :" -"math:`i,j,k`corresponde a :math:`\\sigma_x/\\imath\\ \\sigma_y/\\imath, " -"\\sigma_z/\\imath`. Para ejemplificar, :math:`R = e^{\\varphi \\boldsymbol n " -"\\cdot \\boldsymbol J} \\in \\text{SO}(3)` rota un vector real por :math:`R " -"\\boldsymbol v` y la rotación correspondiente :math:`U = e^{-\\imath\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol \\sigma/2} \\in \\text{SU}(2)` rota el " -"mismo vector a través de :math:`U (\\boldsymbol v \\cdot \\boldsymbol " -"\\sigma) U^\\dagger`. Hay que tener en cuenta que :math:`U \\to -U` logra la " -"misma rotación de SO(3), SU(2) se dice que es una cubierta doble de SO(3) " -"(este mapeo da la representación adjunta de SU(2)). Aquí :math:`-\\imath" -"\\boldsymbol \\sigma = -\\imath (\\sigma_x, \\sigma_y, \\sigma_z) \\cong (i," -"j,k)`." - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" -"SU(2) y SO(3) se ven iguales localmente (sus espacios tangenciales dictados " -"por sus algebras de Lie son isomórficos), pero son diferentes globalmente. " -"Aunque esto suena como un tecnicismo, tiene implicaciones topológicas, pero " -"no vamos a entrar en detalles. La ventaja de esta discusión es que los " -"cuaterniones de la unidad *pueden* utilizarse para emular las rotaciones " -"SO(3)." - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" -"Pero dando un paso atrás, ¿por qué nos molestamos en *emular* SO(3)? Para " -"fines computacionales, ya tenemos algo que funciona: la representación " -"matricial. ¿Por qué necesitamos ambos con un grupo raro que ni siquiera es " -"exactamente lo mismo que SO(3)?" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" -"La respuesta es el costo de la computación, y esto es doble. Primero, un " -"operador de rotación tiene sólo 3 grados de libertad: dos para el vector " -"unitario que es el eje de rotación, y uno para el ángulo de rotación " -"alrededor de ese eje. Una :math:`3\\times 3`, por otro lado tiene 9 " -"elementos. Es una exageración. Por ejemplo, siempre que multipliques dos " -"rotaciones, necesitas multiplicar dos matrices :math:`3\\times 3`, sumando y " -"multiplicando cada elemento. En términos de ciclos de CPU, esto es un " -"esfuerzo desperdiciado y podemos ser más óptimos. La segunda parte son los " -"errores de precisión. Los errores son peores en la representación matricial, " -"porque originalmente, sólo tenemos 3 grados de libertad, lo que significa " -"que podemos tener errores de precisión en el eje y el ángulo (sólo 3 " -"errores), pero sigue siendo un elemento de SO(3), mientras que con las " -"matrices, podemos tener errores en cualquiera de los 9 elementos de la " -"matriz y así incluso podemos tener una matriz que ni siquiera es un elemento " -"de SO(3). Estos errores pueden acumularse rápidamente, especialmente si, por " -"ejemplo, está modificando la orientación de un objeto en cada fotograma " -"haciendo una interpolación suave entre una orientación inicial y una " -"orientación objetivo (discutida más adelante en la sección SLERP)." - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" -"Claro, sabemos que los elementos de SO(3) pueden ser representados usando " -"matrices ortogonales con determinante +1 (de ahí el nombre Ortogonal " -"Especial) de tal manera que :math:`R R^T = I`; en lenguaje sencillo, esto " -"significa que las columnas de :math:`R` forman un conjunto ortonormal de " -"vectores, por lo que podemos eliminar los errores si realizamos `Gram-" -"Schmidt `_ orthonormalization de vez en cuando, y forzarlo a " -"volver a SO(3), de tal forma que sea una matriz de rotación real (aunque " -"todavía muy ruidosa en el eje y el ángulo). Pero esto es costoso y bastante " -"malo en términos de posibles errores." - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" -"Entonces, ¿cuál es la alternativa? ¿Volvemos a la fórmula de Rodrigues y " -"codificamos el comportamiento de :math:`J_i` en nuestro programa? Una " -"alternativa más agradable es, utilizar SU(2) (que sabemos cubre SO(3), ¡dos " -"veces de hecho!), porque el equivalente de la fórmula de Rodrigues es mucho " -"más simple:" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" -"gracias a la buena relación :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (algo así ocurre sólo en la tercera potencia con generadores " -"SO(3), ¿recuerdas? y no nos da la identidad), o si prefieres la versión de " -"cuaternión que se usa más comúnmente para representar al grupo isomórfico " -"Spin(3), ésta es" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" -"En los motores de juego, en lugar de almacenar el ángulo del eje :math:" -"`(\\boldsymbol n(\\phi,\\theta), \\varphi )`par donde :math:`\\phi," -"\\theta`son los ángulos acimut y polar que parametrizan el vector unitario :" -"math:`\\boldsymbol n`, la gente normalmente almacena :math:`\\boldsymbol q= " -"(q_0, q_x, q_y, q_z) \\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}" -"{2} n_x, \\sin\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such " -"that :math:`U = \\boldsymbol q \\cdot (1, i, j, k), para hacer cumplir la " -"condición :math:`|\\boldsymbol q|=1` de vez en cuando por renormalización " -"(nota que si bien puedes ver a muchas personas refiriéndose a :math:`" -"\\boldsymbol q` como un cuaternión, no lo es; :math:`U` es el cuaternión " -"real aquí y :math:`\\boldsymbol q` es sólo un vector artificial que contiene " -"los coeficientes en la expansión del mapa exponencial). Por supuesto, si " -"almacenan :math:`(\\varphi, \\phi, \\theta)`, no hay necesidad de una " -"renormalización porque tal parametrización garantiza la normalización, pero " -"esta elección vendría a costa de calcular un montón de senos y cosenos cada " -"vez que se utilizan, por lo que este es un término medio en términos de " -"errores y velocidad." - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "Así que, las ventajas de esta sección son:" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" -"Las matrices pueden representar SO(3) muy bien, pero son demasiado generales " -"y extravagantes en términos de ciclos de CPU y se comportan mal en presencia " -"de errores de coma flotante ¡y los errores pueden incluso llevar a una " -"matriz que no corresponde en absoluto a una matriz de rotación!" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" -"A todos los efectos prácticos, podemos utilizar un elemento de SU(2) para " -"representar una rotación SO(3). Es una doble cobertura de SO(3), así que no " -"estaríamos perdiendo nada al hacerlo. La razón principal para elegir uno " -"sobre el otro es que la fórmula de Rodrigues SO(3) es un poco incómoda para " -"trabajar, mientras que la expansión de SU(2) es clara, limpia y fácil de " -"utilizar." - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" -"Usando matrices, prácticamente se puede hacer todo lo que se hace con los " -"cuaterniones, y viceversa. Las diferencias reales, como se ha destacado, " -"están en las compensaciones de cálculo, no en las matemáticas." - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" -"La relación entre los cuaterniones y las matrices de rotación 3D es " -"aproximadamente la misma que la relación entre el número complejo :math:" -"`e^{\\imath\\theta}` y una matriz de rotación 2D. Así como el complejo " -"número :math:`\\imath \\cong J_z` rota por :math:`\\pi/2` (que es, como " -"vimos, lo que hace un *generador*), :math:`i,j,k` (que son :math:`\\cong " -"J_x, J_y, J_z`) rotar por :math:`\\pi/2` alrededor de los ejes :math:`x, y, " -"z`; no se conmutan entre sí porque en 3D, el orden de las rotaciones es " -"importante. Debido a este isomorfismo entre sus generadores, una rotación " -"SO(3) :math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}` corresponde " -"a la rotación SU(2) :math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. " -"Esta es una imagen útil para tener una idea sobre los cuaterniones. Mientras " -"que el SO(3) es familiar para mucha gente, la \"fórmula de Rodrigues\" para " -"el SU(2) es mucho más recomendable para la programación de gráficos debido a " -"su simplicidad, y por lo tanto se ven cuaterniones en los motores de juego." - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" -"Esto no significa que los cuaterniones son una generalización de números " -"complejos en nuestra construcción cuando consideramos las rotaciones en un " -"sentido estricto; son más bien la generalización 3D del generador de " -"rotación 2D en un sentido suelto (suelto, porque SO(3) y SU(2) son grupos " -"diferentes). Hay una construcción que generaliza números reales a números " -"complejos a cuaterniones, llamada `Construcción de Cayley-Dickson `_, pero son los " -"siguientes pasos los que producen los objetos tópicos octiones y sedeniones " -"(reservando grupos de Lie excepcionales para octoniones)." - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" -"Nota que no hemos dicho una sola palabra sobre los ángulos de Euler. Tanto " -"en las *representaciones* de la matriz como en las de los cuaterniones, nos " -"ceñimos a la *parametrización* del ángulo del eje. Analizaremos diferentes " -"parametrizaciones más adelante." - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "Representación de la matriz de SO(3)" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "Representación por cuaterniones de SU(2)" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr ":math:`(x,y,z)`" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" -"Matrices para :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr ":math:`i,j,k`" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, puede expandirse " -"con la fórmula de Rodrigues" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` puede expandirse con la " -"fórmula de Rodrigues SU(2)" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" -"En el ejemplo anterior, :math:`r,\\theta,\\phi` son coordenadas esféricas " -"correspondientes a :math:`x,y,z`." - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "Una nota sobre el vector SU(2)" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" -"Anteriormente mencionamos que la rotación de un vector real en SU(2) se " -"realiza a través de :math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = " -"U (\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`, y puede que te " -"estés preguntando qué tiene que ver el vector complejo :math:`|\\psi\\rangle " -"= (\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` " -"mencionado anteriormente con esto. La respuesta es, que hay un vector :math:" -"`|\\psi\\rangle` is the one a single :math:`U` que actúa, y en términos de " -"esto, podemos reescribir :math:`U (\\boldsymbol v \\cdot \\boldsymbol " -"\\sigma) U^\\dagger` como :math:`r U (|\\psi\\rangle \\otimes \\langle " -"\\psi|) U^\\dagger` hasta algún término de identidad trivial, donde :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (esta es la forma en que los " -"vectores complejos son típicamente denotados en la mecánica cuántica y se " -"llama `Notación bra-ket `_: el bra es como el vector y el ket es el `operador adjunto `_, y la gente típicamente omite el :" -"math:`\\otimes` entremedio porque eso ya está implícito cuando multiplicas " -"un ket por un bra, y de la misma manera no hay :math:`\\cdot` cuando " -"multiplicas un bra por un ket ya que eso también está implícito)." - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" -"Por lo tanto, dejando a un lado las preocupaciones notacionales, resumiendo, " -"el vector mencionado anteriormente es, en un sentido generalizado, \"la mitad" -"\" de lo que estamos rotando:" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" -"y cada \"mitad\" va a una de las :math:`U` s a cada lado de la relación " -"modificada/generalizada" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" -"así que todo es compatible, y :math:`|\\psi'\\rangle = U |\\psi(\\boldsymbol " -"v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` es satisfactorio. Esta " -"parametrización de un vector SU(2) se hace típicamente en coordenadas " -"esféricas :math:`\\theta,\\phi` (para :math:`r=1`, porque los vectores de " -"estado están normalizados en la mecánica cuántica), y la esfera se llama " -"`Esfera de Bloch `_)." - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "Parametrización de rotaciones" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" -"A partir de argumentos generales de independencia lineal, está claro que una " -"rotación general en 3D requiere 3 parámetros independientes, lo que se " -"conoce como `Teorema de rotación de Euler `_ que transforman los " -"vectores." - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" -"Hay `diferentes formas de parametrizar rotaciones `_ en el `espacio euclídeo 3D `_ usando 3 parámetros, y " -"pasaremos por los dos más comunes en la programación de juegos." - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "Parametrización del eje-ángulo: :math:`(\\phi, \\theta, \\varphi)`" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" -"Como hemos descubierto, se trata *de la* parametrización de las rotaciones " -"en 3D (o de hecho, en cualquier dimensión), que es también la generalización " -"directa de las rotaciones en 2D, es esto: elegir un eje en el espacio 3D (un " -"vector unitario para especificar una dirección, que tiene dos parámetros " -"independientes, ya que su longitud se fija convencionalmente a 1) y es " -"típicamente parametrizada utilizando `polar and azimuthal angles `_ como :math:`" -"\\boldsymbol n(\\phi,\\theta) = (\\sin\\theta \\cos\\phi, \\sin\\theta \\sin" -"\\phi,\\cos\\theta)` y especificar el ángulo de rotación alrededor de ese " -"eje :math:`\\varphi` (que es el tercer parámetro) cuyo sentido de rotación " -"está fijado por la `regla de la mano derecha `_ (para un sistema de coordenadas a la derecha). " -"Para rotaciones 2D (incrustadas) en el plano :math:`xy`, el eje de rotación " -"se toma como el eje z, y sólo necesitamos especificar el ángulo de rotación. " -"En 3D, el eje de rotación puede estar apuntando hacia cualquier dirección " -"(ya que el eje es un vector unitario, puedes pensar en él como un punto en " -"la esfera unitaria, si quieres). Esta forma de parametrizar las rotaciones " -"se llama parametrización eje-ángulo, y es la más fácil de visualizar de " -"forma intuitiva." - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" -"Otra ventaja de la parametrización del ángulo del eje es que es fácil " -"interpolar entre dos rotaciones diferentes (llamemos a sus parámetros :math:`" -"\\boldsymbol n_1, \\varphi_1` y :math:`\\boldsymbol n_2, \\varphi_2`), lo " -"cual es útil cuando se está cambiando la orientación de un objeto, " -"comenzando desde una orientación inicial dada y yendo hacia una final. Una " -"buena manera de hacer esto se describe en una sección posterior donde " -"describimos SLERP. El resultado es un movimiento suave, en lugar de un " -"movimiento \"brusco\" que puede empezar rápido, ir lento en el medio y " -"volver a ir rápido, etc. Resulta que si una masa se transporta de esta " -"manera, experimenta la menor cantidad de torsión (en comparación con otras " -"trayectorias posibles). Esta forma de interpolar linealmente las rotaciones " -"en la parametrización eje-ángulo se llama Interpolación Lineal Esférica o " -"SLERP, y es casi omnipresente en los juegos." - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" -"Ángulos de Euler (y ángulos Tait-Bryan): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" -"Otra forma de parametrizar rotaciones 3D es considerando una secuencia de al " -"menos 3 rotaciones alrededor de ciertos ejes fijos. Esto podría ser, por " -"ejemplo, \"rotar alrededor del eje :math:`Z por `math:``varphi_1`, luego " -"rotar alrededor del eje ``Y`` por `math:``varphi_2``, y finalmente rotar " -"alrededor del eje :math:`x` por ``math:`\\varphi_3``\". Por supuesto, estos " -"ejes no tienen que ser Z, luego Y, luego X. Mientras dos rotaciones " -"secuenciales no estén alrededor del mismo eje (en cuyo caso se combinarían " -"en una sola rotación, reduciendo así el número de parámetros realmente " -"independientes en 1), pueden ser cualquier cosa. Ni siquiera necesitan estar " -"alineados con ningún eje \"nominal\". Otra cosa importante que hay que tener " -"en cuenta es, si se imagina que hay un sistema de coordenadas local \"pintado" -"\" en el objeto, a medida que pasa por la secuencia de rotación de 3 pasos, " -"que el marco local gira con el objeto en sí, mientras que el marco global, " -"por supuesto, permanece como está. Los ángulos de rotación especificados con " -"respecto a un marco de referencia global y fijo se denominan a veces ángulos " -"de Tait-Bryan. Así que cuando estamos especificando una rotación general en " -"términos de 3 rotaciones alrededor de ciertos ejes \"fijos\", necesitamos " -"especificar si esos ejes se refieren al global (llamado extrínseco, " -"usualmente escrito con un primo adicional, :math:`X'` en lugar de :math:`X`, " -"después de cada rotación) o también al marco local (llamado intrínseco). " -"Típicamente, se utiliza extrínseco, ya que es más fácil de visualizar, y los " -"ejes se eligen para que coincidan con X, Y o Z. Los 3 ángulos de rotación " -"utilizados en esta representación de las rotaciones se llaman ángulos de " -"Euler." - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" -"Antiguos dispositivos mecánicos llamados cardanes (que son obsoletos desde " -"hace mucho tiempo en esta era) utilizados para calcular las rotaciones 3D en " -"aplicaciones de ingeniería en vehículos aumentaron la popularidad de los " -"ángulos de Euler. Además, dado que la matriz de rotación de :math:`3 \\times " -"3` alrededor del eje X,Y o Z es más fácil de escribir, comúnmente se dice " -"que los ángulos de Euler son más fáciles de entender cuando se comparan con " -"la representación eje-ángulo (la cual es normalmente, aunque no " -"necesariamente, implementada a través de cuaterniones). Si bien esto puede " -"ser cierto si está creando una biblioteca de álgebra lineal desde cero, o si " -"está rellenando los elementos de la matriz de transformación por su cuenta, " -"este no es el caso cuando escribe juegos con motores de juego, como Godot. " -"La popularidad de los ángulos de Euler perduró a pesar de que, de hecho, no " -"pueden representar una transición suave entre dos rotaciones diferentes por " -"una variación suave de los tres ángulos. La razón de esto radica en el hecho " -"de que los ángulos de Euler describen una gráfica en 3-toroides, que no es " -"un `espacio recubridor `_ " -"de las rotaciones tridimensionales de SO(3), (si esto suena demasiado " -"abstracto, ver la subsección sobre 3-toroides y esfera abajo). Como el mapeo " -"de los ángulos de Euler a SO(3) está mal definido en ciertos puntos, durante " -"la interpolación suave entre dos rotaciones, podemos toparnos con tales " -"puntos, y como resultado el rango puede caer a 2 o incluso 1 (lo que " -"mecánicamente corresponde a una situación en la que dos o tres balancines se " -"alinean a medida que giran), lo que se conoce como el problema `bloqueo del " -"cardán `_)." -msgstr "" -"Imagina una hormiga caminando sobre la superficie de la rosquilla que se " -"muestra a continuación (imagen tomada de `aquí `_)." - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" -"Si continúa caminando a lo largo de las líneas rojas o azules, eventualmente " -"regresará a donde comenzó. En cualquier momento, podemos usar dos ángulos " -"para describir dónde está la hormiga: uno (:math:`\\theta` que va entre :" -"math:`0` y :math:`2\\pi`) describiendo su posición a lo largo de la línea " -"roja, y otro (:math:`\\phi`, otra vez entre :math:`0` y :math:`2\\pi`) para " -"la línea azul. Y ten en cuenta que tenemos periodicidad: :math:`(\\theta," -"\\phi)` y :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describen exactamente " -"el mismo punto en la rosquilla para un entero `mateh:`N`. Tenemos dos " -"ángulos, por supuesto, porque estamos hablando de una superficie " -"bidimensional. Ahora estamos listos para hablar de :math:`n`-superficies " -"dimensionales." - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" -"Si tenemos un conjunto de :math:`n` \"coordenadas\" (o ángulos) que son " -"periódicas, igual que lo fueron :math:`\\theta` y :math:`\\phi` (que es el " -"caso de los tres ángulos de Euler), entonces la gente dice que esas " -"coordenadas describen un punto en la superficie de un toroide-:math:`n`. (En " -"el caso de que el período de una \"coordenada\" sea diferente a :math:" -"`2\\pi`, esa coordenada puede ser escalada para hacerla así, de tal forma " -"que corresponda a un toroide-:math:`n`)." - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" -"Ahora, volvamos a nuestro número original. El eje de la parametrización eje-" -"ángulo (que es *la* forma natural de parametrizar las rotaciones, y es un " -"mapa de cobertura uno a uno de SO(3); de hecho, esto es válido para todos " -"los grupos de Lie, no sólo para las rotaciones en 3D) abarca una esfera " -"(cada punto en una bola de radio :math:`\\pi` corresponde a una rotación en " -"SO(3) en la que la cantidad de rotación se mapea al radio y los puntos del " -"eje de rotación son la dirección desde el origen; con la advertencia " -"adicional de que si volteas el signo del eje y el ángulo simultáneamente, se " -"mapea a la misma rotación), que se describe usando coordenadas esféricas, " -"mientras que los ángulos de Euler abarcan la superficie de 3-toroides (de " -"tal forma que cada punto en los 3-toroides corresponde a una rotación), que " -"se describe con los tres ángulos de Euler. El problema aquí es que una " -"esfera es topológicamente diferente a un toroide. En términos simples, esto " -"significa que es imposible deformar una esfera a un toroide \"suavemente\": " -"en algún momento, tienes que hacer un agujero en ella para hacer una " -"rosquilla de una bola (y nunca puedes \"perforar un agujero\" o cambiar la " -"topología cuando te quedas con una parametrización: si usas los ángulos de " -"Euler, estás siempre atascado caminando por la superficie de 3-rosquillas, y " -"si usas un eje-ángulo, estás siempre atascado volando dentro de la esfera)." - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" -"¿Por qué es esto un problema? Porque significa que una caminata suave " -"(¿vuelo?) dentro de la esfera no siempre corresponde a una caminata suave en " -"la superficie de 3-toroides, viceversa: 3-toroides y una esfera son " -"completamente diferentes, lo cual es un hecho que estás obligado a descubrir " -"si caminas por el espacio de parámetros girando suavemente un cuerpo usando " -"estas parametrizaciones. La parametrización eje-ángulo tiene singularidades " -"en los polos (donde el ángulo acimutal está mal definido) pero eso está bien " -"porque así es exactamente como está SO(3), después de todo, el eje-ángulo es " -"como se parametrizan los grupos de Lie. La parametrización del ángulo de " -"Euler también tiene singularidades correspondientes a puntos en los que se " -"alinean dos cardanes, pero esas singularidades son diferentes de los polos " -"de SO(3)." - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" -"Supón que estás en un buen punto, una rotación que puede ser parametrizada " -"por ambos ángulos de eje y Euler únicamente. A veces, puede ocurrir que si " -"das un paso equivocado, caigas en un \"agujero\" (es decir, una singularidad " -"en la que infinitamente muchos parámetros corresponden a la misma rotación, " -"como en los polos, todas las opciones para el ángulo acimutal dan la misma " -"rotación, o la situación similar con el bloqueo del cardán) en una " -"parametrización, mientras que puedes continuar un viaje suave en la otra " -"parametrización. Cuando se cae un \"agujero\" usando los ángulos de Euler, " -"se llama bloqueo de cardán, y como puede no haber un \"agujero\" " -"correspondiente cuando se da un paso similar en la esfera, esto nos dice que " -"los ángulos de Euler son una parametrización defectuosa de SO(3)." - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" -"La raíz del problema no es sólo el hecho de que la parametrización del " -"ángulo de Euler tiene singularidades, como lo hace el eje-ángulo, que está " -"bien por sí solo, sino que esas singularidades no coinciden con las " -"singularidades de SO(3)." - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "Esta es la descripción matemática del problema del bloqueo del cardán." - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" -"He aquí un ejemplo de bloqueo del cardán en la parametrización del ángulo de " -"Euler. Supongamos que una de las rotaciones es :math:`\\pi/2`, digamos la " -"del medio. Insertando un operador de identidad :math:`X(-\\pi/2) X(\\pi/2)` " -"en el lado derecho y reorganizando los términos, podemos probar que" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" -"(ver la sección sobre transformación activa más adelante sobre cómo se " -"transforma una matriz de rotación, que también explica por qué y cómo una " -"rotación Z se convierte en una rotación Y cuando está rodeada de :math:`" -"\\pi/2` y :math:`-\\pi/2` X rotaciones) lo que significa que perdimos un " -"grado de libertad: :math:`\\varphi_y-\\varphi_z` efectivamente se convirtió " -"en un único parámetro determinante de la rotación Y y perdimos completamente " -"la primera rotación Z. Puedes seguir pasos similares para mostrar que cuando " -"*cualquiera* de los ángulos YXZ Euler se convierten en :math:`\\pm \\pi/2`, " -"se obtiene un bloqueo de cardán." - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" -"Esto sucede para :math:`\\pm \\pi/2` simplemente porque en la convención " -"YXZ, los ejes vecinos están relacionados entre sí por una rotación de :math:`" -"\\pm \\pi/2` alrededor del eje dado por el otro vecino. Para la convención " -"XZX, el bloqueo del cardán ocurriría por ejemplo en :math:`\\varphi_z = \\pm " -"\\pi`." - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "Resumen: representación vs parametrización" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "Podemos resumirlo en una tabla:" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "Parametrización/Representación" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "Ejes-ángulo" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "Ángulos de Euler" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" -"donde :math:`\\boldsymbol J` denota la representación matricial de los " -"operadores :math:`\\boldsymbol J` (demasiado perezosos para introducir un " -"nuevo símbolo para eso). Los ángulos de Euler XYZ se eligen para concretar " -"(ya que es la convención por defecto en Godot), y pueden ser reemplazados " -"por tres ejes cualquiera (siempre y cuando dos ejes vecinos no sean iguales)." - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" -"En todos los casos enumerados en la tabla anterior, la fórmula de Rodrigues " -"(o es análoga para los cuaterniones) indicada anteriormente puede utilizarse " -"con fines prácticos." - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" -"En el contexto de las rotaciones 3D, una representación no es superior o " -"inferior a otra. Cualquiera que sea la representación que estés usando, " -"estás representando exactamente lo mismo. Las diferencias sólo aparecen " -"cuando se implementan en una computadora: diferentes representaciones tienen " -"compensaciones cuando se trata de errores de precisión, ciclos de CPU y uso " -"de memoria (por ejemplo, acceder al ángulo del eje de rotación con " -"cuaterniones es trivial pero requiere algo de álgebra en la representación " -"de la matriz mientras que lo contrario es aplicable cuando se accede a los " -"vectores base, SLERP, la composición de rotaciones y ortonormalización es " -"más rápida con cuaterniones, pero siempre se requiere una conversión a " -"representación matricial, que no es libre, porque esa es la representación " -"que utiliza OpenGL y girar un vector 3D es más rápido en la representación " -"matricial ya que están escritos en la misma base), y pueden tener " -"características diferentes cuando se hace aritmética de precisión finita con " -"números de coma flotante. En principio, se puede hacer todo lo que se hace " -"con los cuaterniones utilizando matrices, y viceversa. El desempeño podría " -"ser malo en una representación, pero el punto es que no hay nada en sus " -"matemáticas que le impida hacer eso." - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" -"Las parametrizaciones, por otro lado, son muy diferentes. El ángulo del eje " -"es la \"única\" parametrización verdadera de las rotaciones. Los ángulos de " -"Euler, a pesar de ser una parametrización defectuosa de las rotaciones, " -"podrían ser más intuitivos para situaciones simples (involucrando sólo 1 o 2 " -"ángulos) y *estáticas* como orientar una carrocería/vehículo en el editor, " -"pero deberían ser evitados por la *dinámica* rotacional que eventualmente " -"llevaría a un bloqueo del cardán." - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "Interpolación de rotaciones" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" -"En los juegos, es un problema común interpolar entre dos orientaciones " -"diferentes de una manera \"agradable\" que no depende de cosas arbitrarias " -"como el cuadro de referencia, y que no resulta en un movimiento \"brusco" -"\" (es decir, un movimiento sin torsión) tal que la velocidad angular " -"permanece constante durante la interpolación. Estas son las propiedades que " -"buscamos cuando decimos \"agradable\"." - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" -"Nos gustaría interpolar formalmente entre una rotación inicial :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` y una " -"final :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` una " -"función de tiempo, y lo que estamos buscando es algo que se transforme el " -"uno en el otro suavemente, :math:`R(\\lambda)`, donde :math:`\\lambda` es el " -"tiempo normalizado, siendo 0 al principio y 1 al final. Claramente, debemos " -"tener :math:`R(\\lambda=0)=R_1` y :math:`R(\\lambda=1) = R_2`. Como ya " -"sabemos que las rotaciones forman un grupo, podemos relacionar :math:" -"`R(\\lambda)` con :math:`R_1` and :math:`R_2` usando otra rotación, de " -"manera que, por ejemplo, podamos escribir" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" -"Esta forma tiene sentido porque para :math:`\\lambda=0`, la interpolación no " -"ha comenzado y :math:`R(\\lambda)` se convierte automáticamente en :math:" -"`R_1`. Pero, ¿por qué no elegir una forma diferente para el exponente en " -"función de :math:`\\lambda` que se evalúa a 0 cuando :math:`\\lambda=0`? Eso " -"es simplemente porque no queremos tener un movimiento brusco, lo que " -"significa :math:`\\boldsymbol \\omega \\cdot \\boldsymbol J = R^T(\\lambda) " -"\\dot R(\\lambda)`, dónde :math:`\\boldsymbol \\omega` es el vector de " -"velocidad angular, tiene que ser una constante, lo que sólo puede ocurrir si " -"la derivada temporal del exponente es lineal en el tiempo (en cuyo caso " -"obtenemos :math:`\\boldsymbol \\omega = \\varphi \\boldsymbol n`). O su " -"equivalente, simplemente se puede observar que una rotación alrededor de un " -"eje fijo (fijo porque de lo contrario, si inclinas el eje de rotación en el " -"tiempo, obtendrás de nuevo un \"movimiento brusco\" debido a la `Fuerza de " -"Euler ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 +#, fuzzy msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" +"Para obtener más información sobre los eventos propios, consulte el " +"tutorial :ref:`doc_inputevent`." + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 +#, fuzzy msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" "Como ayudante para situaciones en las que quieras crear vistas que muestren " "objetos individuales y no quieras crear un mundo, la vista tiene la opción " "de usar su propio Mundo. Esto es muy útil cuando se desea crear personajes u " "objetos 3D en el mundo 2D." -#: ../../docs/tutorials/viewports/viewports.rst:114 +#: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:119 +#: ../../docs/tutorials/viewports/viewports.rst:125 +msgid "" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:128 msgid "Capture" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:121 +#: ../../docs/tutorials/viewports/viewports.rst:130 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:147 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" -msgstr "" +#: ../../docs/tutorials/viewports/viewports.rst:163 +#, fuzzy +msgid "Viewport Container" +msgstr "Vistas y Canvas items" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 +#: ../../docs/tutorials/viewports/viewports.rst:170 +#, fuzzy msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" "El Viewport cubrirá completamente el área de su control padre, si el " "estiramiento se establece en true en Viewport Container. Pero tendrás que " "configurar el tamaño del Viewport para ver la parte apropiada del Viewport. " "Y el Container Viewport no puede ser más pequeño que el tamaño del Viewport." -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +#: ../../docs/tutorials/viewports/viewports.rst:177 +msgid "" +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:170 +#: ../../docs/tutorials/viewports/viewports.rst:183 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:181 -msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +#, fuzzy +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" +"Este es un buen punto de partida para un juego de plataformas. Se puede " +"encontrar una demostración más completa en el zip de demostración " +"distribuido con el motor, o en https://github.com/godotengine/godot-demo-" +"projects/tree/master/2d/kinematic_character." #: ../../docs/tutorials/viewports/multiple_resolutions.rst:4 msgid "Multiple resolutions" @@ -55482,9 +53554,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -55538,7 +53610,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -60161,6 +58233,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "Vector" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" @@ -65213,6 +63289,2316 @@ msgid "" "`_" msgstr "" +#~ msgid "Rotations" +#~ msgstr "Rotaciones" + +#~ msgid "" +#~ "In the context of 3D transforms, rotations are the nontrivial and " +#~ "complicated part. While it is possible to describe 3D rotations using " +#~ "geometrical drawings and derive the rotation matrices, which is what most " +#~ "people would be more familiar with, it offers a limited picture, and " +#~ "fails to give any insight on related practical things such quaternions " +#~ "and SLERP. For this reason, this document takes a different approach, a " +#~ "general (although a little abstract at first) approach which was " +#~ "popularized by its extensive use in local gauge theories in physics. That " +#~ "being said, the aim of this text is to provide a minimal background to " +#~ "understand 2D and 3D rotations in a general way and shed light on " +#~ "practical things such as gimbal lock, quaternions and SLERP using an " +#~ "accessible language for programmers, and not completeness or mathematical " +#~ "rigor." +#~ msgstr "" +#~ "En el contexto de las transformaciones 3D, las rotaciones son la parte no " +#~ "trivial y complicada. Mientras que es posible describir rotaciones 3D " +#~ "usando dibujos geométricos y derivar las matrices de rotación, que es con " +#~ "lo que la mayoría de la gente estaría más familiarizada, ofrece una " +#~ "imagen limitada, y no da ninguna idea de las cosas prácticas relacionadas " +#~ "tales como cuaterniones y SLERP. Por esta razón, este documento adopta un " +#~ "enfoque diferente, un enfoque general (aunque un poco abstracto al " +#~ "principio) que fue popularizado por su uso extensivo en las teorías de " +#~ "los indicadores locales en física. Dicho esto, el objetivo de este texto " +#~ "es proporcionar una base mínima para entender las rotaciones 2D y 3D de " +#~ "una manera general y arrojar luz sobre cosas prácticas como el bloqueo " +#~ "del cardán, los cuaterniones y SLERP utilizando un lenguaje accesible " +#~ "para los programadores, y no la integridad o el rigor matemático." + +#~ msgid "A crash course in Lie groups and algebras for programmers" +#~ msgstr "Un curso intensivo en grupos de Lie y álgebra para programadores" + +#~ msgid "" +#~ "Lie groups is a branch of mathematics which deals with rotations in a " +#~ "systematic way. While it is a extensive subject and most programmers " +#~ "haven't even heard of it, it is relevant in game development, because it " +#~ "provides a coherent and unified view of 3D rotations." +#~ msgstr "" +#~ "Los grupos de Lie son una rama de las matemáticas que se ocupa de las " +#~ "rotaciones de manera sistemática. Aunque es un tema extenso y la mayoría " +#~ "de los programadores ni siquiera han oído hablar de él, es relevante en " +#~ "el desarrollo de juegos, porque proporciona una visión coherente y " +#~ "unificada de las rotaciones 3D." + +#~ msgid "" +#~ "So let's start with small steps. Suppose that you want to make a tiny " +#~ "rotation around some axis. For, concreteness let's say around :math:`z`-" +#~ "axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, " +#~ "as illustrated in the figure, the rotation operator can be written as :" +#~ "math:`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " +#~ "(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " +#~ "where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a " +#~ "unit vector along the :math:`z`-axis, such that a vector :math:`" +#~ "\\boldsymbol v` becomes" +#~ msgstr "" +#~ "Así que empecemos con pequeños pasos. Imaginemos que queremos hacer una " +#~ "pequeña rotación alrededor de algún eje. Para concretar, digamos " +#~ "alrededor del eje :math:`z` por un ángulo infinitesimal `:math:`\\delta" +#~ "\\theta`. Para ángulos pequeños, como se ilustra en la figura, el " +#~ "operador de rotación puede escribirse como :math:`R_z(\\delta\\theta) = I " +#~ "+ \\delta \\theta \\boldsymbol e_z \\times`donde :math:`I` es operador de " +#~ "identidad y :math:`\\boldsymbol e_z` es un vector unitario a lo largo del " +#~ "eje :math:`z`, de manera que un vector :math:`\\boldsymbol v` se " +#~ "convierte en" + +#~ msgid "" +#~ "(If this isn't clear, you can verify this by looking at the figure: :math:" +#~ "`\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so " +#~ "the rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). " +#~ "The overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol " +#~ "v' = v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` " +#~ "since the rotation is just a tiny amount, so the part of :math:`" +#~ "\\boldsymbol v'` parallel to :math:`\\boldsymbol v` is indeed :math:`" +#~ "\\boldsymbol v`. Here, :math:`v = |\\boldsymbol v|`. What about the " +#~ "perpendicular part, which must be :math:`\\boldsymbol v' - \\boldsymbol " +#~ "v`? Using the right-hand rule, the direction is :math:`\\boldsymbol e_z " +#~ "\\times \\boldsymbol v/v`, and to the first order in :math:`\\delta" +#~ "\\theta`, we can approximate the length of the difference vector by the " +#~ "arc length (blue arc in the figure) which is :math:`\\delta \\theta v`, " +#~ "so the perpendicular component :math:`\\delta \\theta \\boldsymbol e_z " +#~ "\\times \\boldsymbol v` also checks out.)" +#~ msgstr "" +#~ "(Si esto no está claro, puedes verificar esto mirando la figura: :math:`" +#~ "\\boldsymbol v` es rotado dentro de :math:`\\boldsymbol v'` en el plano " +#~ "(así que el eje de rotación :math:`\\boldsymbol e_z` está apuntando fuera " +#~ "de la pantalla). La superposición de dos vectores es :math:`\\boldsymbol " +#~ "v \\cdot \\boldsymbol v' = v^2\\cos\\delta\\theta \\approx v^2 + " +#~ "\\mathcal O(\\delta\\theta^2)` ya que la rotación es muy reducida, así " +#~ "que la parte de :math:`\\boldsymbol v'`paralela a :math:`\\boldsymbol v` " +#~ "es en realidad :math:`\\boldsymbol v`. Aquí,:math:`v = |\\boldsymbol v|`. " +#~ "¿Qué hay de la parte perpendicular, que debe ser :math:`\\boldsymbol v' - " +#~ "\\boldsymbol v`? Usando la regla de la mano derecha, la dirección es :" +#~ "math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, y de primer orden en :" +#~ "math:`\\delta\\theta`, podemos aproximar la longitud del vector de " +#~ "diferencia por la longitud del arco (arco azul en la figura) que es :math:" +#~ "`\\delta \\theta v` así que el componente perpendicular :math:`\\delta " +#~ "\\theta \\boldsymbol e_z \\times \\boldsymbol v` también es comprobado.)" + +#~ msgid "" +#~ "Now, a practical way of representing operators is by using matrices (note " +#~ "that an `operator `_ is not a matrix, and there are different " +#~ "mathematical objects other than matrices which be used to represent " +#~ "operators, such as quaternions, a point which we will come back to later " +#~ "when we're discussing `representations `_ . In terms of real :math:`3 \\times 3` matrices, " +#~ "the identity operator :math:`I` simply corresponds to a :math:`3 \\times " +#~ "3` identity matrix, and the cross product :math:`\\boldsymbol e_z " +#~ "\\times` can be represented as" +#~ msgstr "" +#~ "Ahora, una forma práctica de representar operadores es usando matrices " +#~ "(note que un `operador `_ no es una matriz, y hay diferentes objetos " +#~ "matemáticos aparte de las matrices que se usan para representar " +#~ "operadores, tales como cuaterniones, un punto al cual volveremos más " +#~ "tarde cuando estemos discutiendo `representaciones ``_. En términos de matrices reales de :" +#~ "matemáticas:`3 \\por 3`, el operador de identidad :math:`I` simplemente " +#~ "corresponde a un :math:`3 \\times 3` matriz de identidad, y el producto " +#~ "cruzado :math:`\\boldsymbol e_z \\times` puede representarse como" + +#~ msgid "" +#~ "(If you're curious how you can find the matrix representation of an " +#~ "operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i" +#~ "\\}`: the matrix element on :math:`i` th row :math:`j` th column is given " +#~ "by :math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use " +#~ "here is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z " +#~ "\\}`) It is no accident that :math:`J_z` rotates a vector in the :math:" +#~ "`xy` plane around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary " +#~ "axis :math:`\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol " +#~ "n \\times` is a rotation by :math:`\\pi/2` around that axis for vectors " +#~ "in the plane perpendicular to :math:`\\boldsymbol n`." +#~ msgstr "" +#~ "(Si tienes curiosidad por saber cómo encontrar la representación " +#~ "matricial de un operador :math:`A` en algún tipo de base real :math:`" +#~ "\\{ \\boldsymbol e_i\\}`: el elemento matriz en :math:`i` fila anterior :" +#~ "math:`j` esta columna viene dada por :math:`\\boldsymbol e_i \\cdot (A " +#~ "\\boldsymbol e_j)`; la base que usamos aquí es :math:`\\{ \\boldsymbol " +#~ "e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) No es casualidad que :math:" +#~ "`J_z` rotará un vector en el plano :math:`xy` alrededor del eje :math:`z` " +#~ "por :math:`\\pi/2`; para un eje arbitrario :math:`\\boldsymbol n` el " +#~ "operador :math:`J_n \\cong \\boldsymbol n \\times` es rotado por :math:`" +#~ "\\pi/2` alrededor de ese eje para vectores en el plano perpendicular a :" +#~ "math:`\\boldsymbol n`." + +#~ msgid "" +#~ "In terms of :math:`J_z`, we can express the infinitesimal rotation " +#~ "operator around the :math:`z`-axis as" +#~ msgstr "" +#~ "En términos de :math:`J_z`, podemos expresar el operador de rotación " +#~ "infinitesimal alrededor del eje :math:`z` como" + +#~ msgid "" +#~ "So, how about finite rotations? We simply can apply this infinitesimal " +#~ "rotation operator :math:`N` times to obtain a finite rotation :math:`" +#~ "\\theta \\equiv N \\delta \\theta`:" +#~ msgstr "" +#~ "Entonces, ¿qué tal rotaciones finitas? Simplemente podemos aplicar este " +#~ "operador de rotación infinitesimal :math:`N` veces para obtener una " +#~ "rotación finita :math:`\\theta \\equiv N \\delta \\theta`:" + +#~ msgid "" +#~ "(If you're confused about seeing a matrix as an exponent: the meaning of " +#~ "an operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" +#~ "`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " +#~ "relation in this write up, and lies at the heart of Lie groups, whose " +#~ "significance will be clarified in a moment. But first, let's take step " +#~ "back and observe the significance of this result: using a simple picture " +#~ "of an infinitesimal rotation, we derived a general expression for " +#~ "arbitrary rotations around the :math:`z`-axis. In fact, this gets even " +#~ "better. If we repeated the same analysis for rotations around :math:`x`- " +#~ "and :math:`y`-axes, we would have obtained similar results :math:" +#~ "`e^{\\theta J_x}` and :math:`e^{\\theta J_y}` respectively, where" +#~ msgstr "" +#~ "(Si estás confundido acerca de ver una matriz como un exponente: el " +#~ "significado de un operador :math:`A` en un `mapa exponencial `_ está dado por la " +#~ "expansión de su serie como :math:`e^A = 1 + A + A^2/2! + \\ldots` ). Esta " +#~ "es posiblemente la relación más importante en este artículo, y se sitúa " +#~ "en el corazón de los grupos de Mentiras, cuyo significado será aclarado " +#~ "próximamente. Pero primero, demos un paso atrás y observemos el " +#~ "significado de este resultado: usando una simple imagen de una rotación " +#~ "infinitesimal, derivamos una expresión general para rotaciones " +#~ "arbitrarias alrededor del eje :math:`z`. De hecho, esto se pone aún " +#~ "mejor. Si hubiéramos repetido el mismo análisis para rotaciones alrededor " +#~ "de los ejes :math:`x` y :math:`y`, habríamos obtenido resultados " +#~ "similares a :math:`e^{\\theta J_y}` y :math:`e^{\\theta J_y}` " +#~ "respectivamente, donde" + +#~ msgid "" +#~ "Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " +#~ "the result would have been" +#~ msgstr "" +#~ "O, si hubiéramos hecho una rotación alrededor de un eje arbitrario :math:`" +#~ "\\boldsymbol n`, el resultado habría sido" + +#~ msgid "" +#~ "where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation " +#~ "axis :math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a " +#~ "central role in the final expression. Axis-angle is *the* parametrization " +#~ "for *all* Lie groups, not just 3D rotations. (We will come back to this " +#~ "point later when we're discussing Euler angle parametrization, which is " +#~ "an unnatural and defective parametrization of rotations in 3D.)" +#~ msgstr "" +#~ "donde :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Observa cómo el eje de " +#~ "rotación :math:`\\boldsymbol n` y el ángulo de rotación :math:`\\theta` " +#~ "juegan un papel central en la expresión final. Eje-ángulo es *la* " +#~ "parametrización para *todos* los grupos de Lie, no sólo las rotaciones " +#~ "3D. (Volveremos a este punto más adelante cuando discutamos la " +#~ "parametrización del ángulo de Euler, que es una parametrización " +#~ "antinatural y defectuosa de las rotaciones en 3D.)" + +#~ msgid "" +#~ "If you ever tried to derive the rotation matrix corresponding to a :math:`" +#~ "\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " +#~ "simplicity and elegance of how we obtained this result. To be fair, we " +#~ "still need to figure out how to actually use an operator sitting on top " +#~ "of an exponent (by summing up the Taylor series), of course, but that's " +#~ "merely a \"programmatic\" labor and you just need to follow the finite " +#~ "multiplication table of :math:`J_i` operators. But this is much " +#~ "straightforward than trying to draw geometric diagrams and angles and " +#~ "figure out the rotation matrix. For the particular case of the algebra " +#~ "corresponding to rotations in 3D Euclidean space that we've been talking " +#~ "about so far, the exponent can simply be written as" +#~ msgstr "" +#~ "Si alguna vez has intentado derivar la matriz de rotación correspondiente " +#~ "a una rotación :math:`\\theta` alrededor de :math:`\\boldsymbol n`, " +#~ "puedes apreciar la simplicidad y elegancia de cómo obtuvimos este " +#~ "resultado. Para ser justos, todavía necesitamos averiguar cómo usar un " +#~ "operador situado encima de un exponente (resumiendo la serie de Taylor), " +#~ "por supuesto, pero eso es meramente una labor \"programática\" y sólo " +#~ "necesitamos seguir la tabla de multiplicación finita de operadores :math:" +#~ "`J_i`. Pero esto es mucho más sencillo que tratar de dibujar diagramas " +#~ "geométricos y ángulos y calcular la matriz de rotación. Para el caso " +#~ "particular del álgebra correspondiente a las rotaciones en el espacio " +#~ "Euclídeo 3D del que hemos estado hablando hasta ahora, el exponente puede " +#~ "escribirse simplemente como" + +#~ msgid "" +#~ "which is known as Rodrigues' rotation formula. Note that we only ended up " +#~ "with terms up to second order in :math:`\\boldsymbol n \\cdot " +#~ "\\boldsymbol J` when we summed the series expansion; the reason is higher " +#~ "powers can be reduced to 0th, 1st or 2nd order terms due to the relation :" +#~ "math:`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " +#~ "\\boldsymbol J`, which makes summing up the series straightforward." +#~ msgstr "" +#~ "que se conoce como la fórmula de rotación de Rodrigues. Nótese que sólo " +#~ "terminamos con términos de segundo orden en :math:`\\boldsymbol n \\cdot " +#~ "\\boldsymbol J` cuando sumamos la expansión de la serie; la razón es que " +#~ "las potencias superiores pueden ser reducidas a términos de 0º, 1er o 2º " +#~ "orden debido a la relación :math:`(\\boldsymbol n \\cdot \\boldsymbol " +#~ "J)^3 = -\\boldsymbol n \\cdot \\boldsymbol J`, lo que hace que resumir la " +#~ "serie sea sencillo." + +#~ msgid "" +#~ "The thing that sits on top of :math:`e`, which is a linear combination :" +#~ "math:`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in " +#~ "fact, it forms a vector space whose basis \"vectors\" are :math:`J_i`. " +#~ "Furthermore, the algebra is closed under the Lie bracket (which is " +#~ "essentially a commutator: :math:`[a,b] = a b - ba`, and is something like " +#~ "a cross-product in this vector space). In the particular case of 3D " +#~ "rotations, this \"multiplication table\" is :math:`[J_x, J_y] = J_z` and " +#~ "its cyclic permutations :math:`x\\to y, y\\to z, z\\to x`." +#~ msgstr "" +#~ "Lo que se encuentra encima de los operadores :math:`e`, que es una " +#~ "combinación lineal :math:`J_i` (donde :math:`i = x,y,z`), forma un " +#~ "álgebra; de hecho, forma un espacio vectorial cuyos \"vectores\" base " +#~ "son :math:`J_i`. Además, el álgebra se cierra bajo el corchete de Lie " +#~ "(que es esencialmente un conmutador: :math:`[a,b] = a b - ba`, y es algo " +#~ "así como un producto cruzado en este espacio vectorial). En el caso " +#~ "particular de las rotaciones 3D, esta \"tabla de multiplicación\" es :" +#~ "math:`[J_x, J_y] = J_z` and its cyclic permutations :math:`x\\to y, y\\to " +#~ "z, z\\to x`." + +#~ msgid "" +#~ "Rotations form what is called a `group `_: simply put, it means that if you combine two " +#~ "rotations, you get another rotation. And you can observe it here too: " +#~ "when you put an element of the Lie algebra (which are simply linear " +#~ "combinations of :math:`J_i` ) on top of :math:`e`, you get what is called " +#~ "a Lie group, and the Lie algebra is said to *generate* the Lie group. For " +#~ "example, the operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is " +#~ "said to *generate* the rotations around the :math:`z`-axis. The group of " +#~ "rotations in the 3D Euclidean space is called SO(3)." +#~ msgstr "" +#~ "Las rotaciones forman lo que se llama un `grupo `_: en pocas palabras, significa que si " +#~ "combinas dos rotaciones, obtienes otra rotación. Y puedes observarlo aquí " +#~ "también: cuando pones un elemento del álgebra de Lie (que son simplemente " +#~ "combinaciones lineales de :math:`J_i`) encima de :math:`e`, obtienes lo " +#~ "que se llama un grupo de Lie, y se dice que el álgebra de Lie *genera* el " +#~ "grupo de Lie. Por ejemplo, se dice que el operador :math:`J_z \\equiv " +#~ "\\boldsymbol e_z \\times` *genera* las rotaciones alrededor del eje `z`. " +#~ "El grupo de rotaciones en el espacio euclídeo 3D se llama SO(3)." + +#~ msgid "" +#~ "The order of rotations in 2D don't matter: you can first rotate by :math:`" +#~ "\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " +#~ "way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " +#~ "order of rotations in 3D do matter, in general, when different rotation " +#~ "axes are involved (see `this picture `_ for an example) (rotations around the same axes do commute, of " +#~ "course). When the ordering of group elements don't matter, that group is " +#~ "said to be Abelian, and non-Abelian otherwise. SO(2) is an Abelian group, " +#~ "and SO(3) is a non-Abelian group." +#~ msgstr "" +#~ "El orden de rotaciones en 2D no importa: primero puedes rotar por :math:`" +#~ "\\pi` y rotar por :math:`\\pi/2`, o hacerlo en orden inverso, y de " +#~ "cualquier manera, el resultado es una rotación por :math:`3 \\pi/2` en el " +#~ "plano. Pero el orden de las rotaciones en 3D importa, en general, cuando " +#~ "se trata de diferentes ejes de rotación (ver `esta imagen `_ para un ejemplo) (las rotaciones alrededor " +#~ "de los mismos ejes viajan, por supuesto). Cuando el orden de los " +#~ "elementos del grupo no importa, se dice que ese grupo es abeliano, y de " +#~ "otra manera no abeliano. SO(2) es un grupo abeliano, y SO(3) es un grupo " +#~ "no-abeliano." + +#~ msgid "" +#~ "Lie groups and algebras are *not* matrices. You can *represent* both by " +#~ "using object which emulate their \"multiplication\" rules: this can be " +#~ "real or complex matrices of varying dimensions, or something like " +#~ "quaternions. A single Lie group/algebra have infinitely many different " +#~ "representations in vector spaces in different dimensions (see `these " +#~ "`_ for example for SO(3)). " +#~ "Above, we use the 3D real representation of SO(3), which happens to be " +#~ "the fundamental representation, and accidentally coincides with the " +#~ "adjoint representation." +#~ msgstr "" +#~ "Los grupos de Lie y las algebras *no* son matrices. Se pueden " +#~ "*representar* ambos usando objetos que emulen sus reglas de " +#~ "\"multiplicación\": pueden ser matrices reales o complejas de dimensiones " +#~ "variables, o algo así como cuaterniones. Un solo grupo de Lie/álgebra " +#~ "tiene infinitamente muchas representaciones diferentes en espacios " +#~ "vectoriales de diferentes dimensiones (ver `esto `_ por ejemplo para " +#~ "SO(3)). Arriba, utilizamos la representación real 3D de SO(3), que " +#~ "resulta ser la representación fundamental, y coincide accidentalmente con " +#~ "la representación adjunta." + +#~ msgid "Some mathematical remarks (feel free to skip)" +#~ msgstr "Algunos comentarios matemáticos (siéntete libre de omitirlos)" + +#~ msgid "" +#~ "There are many different Lie groups, corresponding to different " +#~ "symmetries, and they all have different names. For example, the group " +#~ "which contains all rotations in :math:`n`-dimensional Euclidean space is " +#~ "called SO(:math:`n`), and has :math:`n (n-1)/2` linearly independent " +#~ "generators (yes, Lie groups can handle rotations is higher dimensions as-" +#~ "is, and even in non-Euclidean ones). This is called the *rank* of the Lie " +#~ "algebra. You can think of the generators as independent axes of " +#~ "rotations. For 2D, we can only rotate in the :math:`xy` plane meaning we " +#~ "have only 1 generator. For 3D, you can rotate around 3 different planes/" +#~ "axes." +#~ msgstr "" +#~ "Hay muchos grupos de Lie diferentes, que corresponden a diferentes " +#~ "simetrías, y todos tienen diferentes nombres. Por ejemplo, el grupo que " +#~ "contiene todas las rotaciones en el espacio euclidiano :math:`n`-" +#~ "dimensional se llama SO(:math:`n`), y tiene :math:`n (n-1)/2` generadores " +#~ "linealmente independientes (sí, los grupos de Lie pueden manejar " +#~ "rotaciones de dimensiones más altas tal cual, e incluso en los no " +#~ "euclidianos). Esto se llama el *rango* del álgebra de Lie. Se puede " +#~ "pensar en los generadores como ejes de rotación independientes. Para 2D, " +#~ "sólo podemos rotar en el plano :math:`xy` lo que significa que sólo " +#~ "tenemos 1 generador. Para 3D, se puede rotar alrededor de 3 planos/ejes " +#~ "diferentes." + +#~ msgid "" +#~ "Lie groups have deep connections with symmetries, and have played central " +#~ "role in theoretical physics since around mid 20th century." +#~ msgstr "" +#~ "Los grupos de Lie tienen profundas conexiones con las simetrías y han " +#~ "jugado un papel central en la física teórica desde mediados del siglo XX." + +#~ msgid "" +#~ "For example, if something is symmetric under 3D rotation, that something " +#~ "(in physics, it is typically Lagrangian, which leads to conservation laws " +#~ "through Noether's theorem) remains invariant under SO(3) transformations " +#~ "(we will cover transformations below)." +#~ msgstr "" +#~ "Por ejemplo, si algo es simétrico bajo rotación 3D, ese algo (en física, " +#~ "es típicamente lagrangiano, lo que lleva a las leyes de conservación a " +#~ "través del teorema de Noether) permanece invariable bajo las " +#~ "transformaciones SO(3) (cubriremos las transformaciones a continuación)." + +#~ msgid "" +#~ "In the context of Lie groups and group theory in general, some common " +#~ "words have specific meanings and a part of the math jargon: " +#~ "representation, generator, group, algebra, parametrization, operator are " +#~ "such words. You don't need to know their precise definitions to " +#~ "understand this write up; just be aware that they are special terms and " +#~ "may not mean what you think they mean. All of these terms a described in " +#~ "this write up in a colloquial language." +#~ msgstr "" +#~ "En el contexto de los grupos de Lie y la teoría de grupos en general, " +#~ "algunas palabras comunes tienen significados específicos y una parte de " +#~ "la jerga matemática: representación, generador, grupo, álgebra, " +#~ "parametrización, operador son tales palabras. No es necesario que " +#~ "conozcas sus definiciones precisas para entender esta redacción; sólo ten " +#~ "en cuenta que son términos especiales y pueden no significar lo que crees " +#~ "que significan. Todos estos términos se describen en este artículo en un " +#~ "lenguaje coloquial." + +#~ msgid "Representation of rotations" +#~ msgstr "Representación de rotaciones" + +#~ msgid "" +#~ "Representation of rotations is an independent concept from " +#~ "parametrization of rotations. These two concepts are commonly conflated, " +#~ "which leads to the current state of confusion among many programmers. " +#~ "People tend to associate Euler angles parametrization with matrices (or " +#~ "sometimes even vectors!), and axis-angle parametrization with quaternions." +#~ msgstr "" +#~ "La representación de rotaciones es un concepto independiente de la " +#~ "parametrización de rotaciones. Estos dos conceptos son comúnmente " +#~ "mezclados, lo que lleva al estado actual de confusión entre muchos " +#~ "programadores. La gente tiende a asociar la parametrización de los " +#~ "ángulos de Euler con matrices (¡o a veces incluso con vectores!), y la " +#~ "parametrización del eje-ángulo con cuaterniones." + +#~ msgid "" +#~ "In game engines, rotation operators are represented using either " +#~ "matrices, or quaternions. *As will be clear in what follows, you can use " +#~ "a matrix or a quaternion to represent a rotation parameterized using " +#~ "Euler angles, and same goes for axis-angle parametrization.* " +#~ "Unfortunately, even graphics programming books and documentations of " +#~ "expensive game engines often make a mistake here, and this causes " +#~ "programmers to start comparing Euler angles (a parametrization) to " +#~ "quaternions (a representation) and even discussing their trade-offs, " +#~ "which is \"not even wrong\"." +#~ msgstr "" +#~ "En los motores de juego, los operadores de rotación se representan " +#~ "utilizando matrices o cuaterniones. Desafortunadamente, incluso los " +#~ "libros de programación de gráficos y las documentaciones de motores de " +#~ "juego caros a menudo cometen un error aquí, y esto hace que los " +#~ "programadores comiencen a comparar los ángulos de Euler (una " +#~ "parametrización) con los cuaterniones (una representación) e incluso a " +#~ "discutir sus equilibrios, lo que \"ni siquiera es incorrecto\"." + +#~ msgid "" +#~ "`Representation `_ " +#~ "here refers to a technical term in group theory. So will many other " +#~ "things that will be mentioned in what follows. To gain a basic understand " +#~ "of these concepts, let's first go through simpler and better understood " +#~ "example of rotations in 2D first." +#~ msgstr "" +#~ "`Representación de grupo `_ aquí se refiere a un término técnico de la teoría de " +#~ "grupos. Así como muchas otras cosas que se mencionarán en lo que sigue. " +#~ "Para obtener una comprensión básica de estos conceptos, primero pasemos a " +#~ "través de ejemplos más simples y mejor entendidos de rotaciones en 2D." + +#~ msgid "Representation of rotations in 2D" +#~ msgstr "Representación de rotaciones en 2D" + +#~ msgid "" +#~ "Since there is only one possible axis of rotation in a two dimensional " +#~ "plane, there is no Euler angle parametrization for them (or if you like, " +#~ "there is only one Euler-angle). Rather, axis-angle parametrization is " +#~ "used, with the axis being fixed to z-axis, which leaves only the angle of " +#~ "rotation :math:`\\varphi` as a free parameter." +#~ msgstr "" +#~ "Dado que sólo hay un eje de rotación posible en un plano bidimensional, " +#~ "no hay parametrización del ángulo de Euler para ellos (o si lo prefieres, " +#~ "sólo hay un ángulo de Euler). En su lugar, se utiliza la parametrización " +#~ "eje-ángulo, fijando el eje al eje z, lo que deja sólo el ángulo de " +#~ "rotación :math:`\\varphi` como parámetro libre." + +#~ msgid "" +#~ "A point in the 2D Euclidean space can be represented by a pair of 2D real " +#~ "numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), " +#~ "or they can alternatively be represented by a complex number as :math:`v " +#~ "= x + \\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit " +#~ "imaginary number. In the vector representation, we can rotate the point " +#~ "through a rotation matrix (an element of the Lie group SO(2), which can " +#~ "be represented by :math:`2 \\times 2` orthogonal matrices with " +#~ "determinant +1) as follows:" +#~ msgstr "" +#~ "Un punto en el espacio 2D euclidiano puede ser representado por un par de " +#~ "números reales 2D como :math:`\\boldsymbol v = (x,y)` (llamado " +#~ "representación vectorial), o alternativamente pueden ser representados " +#~ "por un número complejo como :math:`v = x + \\imath y` donde :math:`" +#~ "\\imath \\equiv \\sqrt{-1}` es un número imaginario de la unidad. En la " +#~ "representación vectorial, podemos rotar el punto a través de una matriz " +#~ "de rotación (un elemento del grupo Lie SO(2), el cual puede ser " +#~ "representado por matrices ortogonales :math:`2 \\times 2` con " +#~ "determinante +1) como sigue:" + +#~ msgid "" +#~ "So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " +#~ "\\boldsymbol v = (-y,x)`." +#~ msgstr "" +#~ "Así, por ejemplo, cuando :math:`\\theta=\\pi/2`, obtenemos :math:" +#~ "`R(\\pi/2) \\boldsymbol v = (-y,x)`." + +#~ msgid "" +#~ "In the complex representation, a rotation is represented by a unit " +#~ "complex number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin" +#~ "\\theta`, where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " +#~ "represented by complex numbers of unit norm. Again, for :math:`\\theta=" +#~ "\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" +#~ "\\imath y) = (-y) + \\imath x`." +#~ msgstr "" +#~ "En la representación compleja, una rotación está representada por un " +#~ "número complejo de unidades :math:`e^{\\imath\\theta} = \\cos\\theta + " +#~ "\\imath \\sin\\theta`, donde usamos la `fórmula de Euler `_, es un elemento del grupo de " +#~ "Lie U(1), que puede ser representado por números complejos de la norma " +#~ "unitaria. Una vez más, para :math:`\\theta=\\pi/2`, recuperas :math:" +#~ "`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+\\imath y) = (-y) + \\imath " +#~ "x`." + +#~ msgid "" +#~ "Rotations in the complex number representation look simpler, but it's " +#~ "only an illusion: the complications of performing a matrix multiplication " +#~ "is absorbed by the introduction of something that lives outside of the " +#~ "realm of real numbers, which follows a rather \"odd\" algebra: :math:`" +#~ "\\imath^2 = -1`. The way complex numbers mimic 2D rotations can be made " +#~ "clearer if we rewrite the rotation matrix in terms of" +#~ msgstr "" +#~ "Las rotaciones en la representación de números complejos parecen más " +#~ "simples, pero es sólo una ilusión: las complicaciones de realizar una " +#~ "multiplicación matricial son absorbidas por la introducción de algo que " +#~ "vive fuera del reino de los números reales, que sigue a un álgebra " +#~ "bastante \"extraña\": :math:`\\imath^2 = -1`. La manera en que los " +#~ "números complejos imitan las rotaciones 2D puede ser más clara si " +#~ "reescribimos la matriz de rotación en términos de" + +#~ msgid "" +#~ "as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can " +#~ "then be compared to :math:`1 x + \\imath y` directly. Now we can see the " +#~ "equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " +#~ "through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, " +#~ "J_z I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 " +#~ "\\times 1 = 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, " +#~ "\\imath \\times \\imath = -1`. Also note that both :math:`\\imath` and :" +#~ "math:`J_z` represent a :math:`\\pi/2` rotation. And as it should be, :" +#~ "math:`\\imath` and :math:`J_z` behave the same under multiplication." +#~ msgstr "" +#~ "que puede ser comparada con :math:`R(\\theta) = I_2 \\cos\\theta + J_z " +#~ "\\sin\\theta`directamente. Ahora podemos ver la equivalencia (el término " +#~ "técnico es `isomorfismo `_ en este contexto) de las representaciones más claras " +#~ "a través de su tabla de multiplicación: :math:`I_2 I_2 = I_2, I_2 J_z = " +#~ "J_z, J_z I_2 = J_z, J_z J_z = -I_2` lo cual se comporta de la misma " +#~ "manera que :math:`1 \\times 1 = 1, 1 \\times \\imath = \\imath, \\imath " +#~ "\\times 1 = \\imath, \\imath \\times \\imath = -1`. También ten en cuenta " +#~ "que tanto :math:`\\imath` como :math:`J_z` representan una rotación de :" +#~ "math:`\\pi/2`. Y como debe ser, :math:`\\imath` and :math:`J_z` se " +#~ "comportan igual en la multiplicación." + +#~ msgid "" +#~ "Furthermore, by Taylor series expansion, it is straightforward to show " +#~ "that :math:`R(\\theta) = e^{J_z \\theta}`." +#~ msgstr "" +#~ "Además, mediante la expansión de la serie de Taylor, es sencillo mostrar " +#~ "que :math:`R(\\theta) = e^{J_z \\theta}`." + +#~ msgid "What" +#~ msgstr "Lo que" + +#~ msgid "Matrix representation of SO(2)" +#~ msgstr "Representación de la matriz de SO(2)" + +#~ msgid "Complex representation of U(1)" +#~ msgstr "Representación compleja de U(1)" + +#~ msgid ":math:`(x,y)`" +#~ msgstr ":math:`(x,y)`" + +#~ msgid ":math:`x+\\imath y`" +#~ msgstr ":math:`x+\\imath y`" + +#~ msgid "Generator" +#~ msgstr "Generador" + +#~ msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" +#~ msgstr "" +#~ ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" + +#~ msgid ":math:`J_z \\cong \\imath`" +#~ msgstr ":math:`J_z \\cong \\imath`" + +#~ msgid "Rotation operator" +#~ msgstr "Operador de rotación" + +#~ msgid "" +#~ ":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " +#~ "\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos" +#~ "\\theta \\end{pmatrix}`" +#~ msgstr "" +#~ ":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " +#~ "\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos" +#~ "\\theta \\end{pmatrix}`" + +#~ msgid "" +#~ ":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + " +#~ "\\imath \\sin\\theta`" +#~ msgstr "" +#~ ":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + " +#~ "\\imath \\sin\\theta`" + +#~ msgid "" +#~ "Clearly, introduction of the unit imaginary number is enough to capture " +#~ "the behavior of 2D rotation matrices. As a footnote remark, while the " +#~ "number :math:`e^{\\imath\\theta}` can only represent a rotation matrix, " +#~ "it can't of course represent an arbitrary :math:`2 \\times 2` matrix " +#~ "(meaning no scaling, no shearing, etc): after all, U(1) isn't isomorphic " +#~ "to :math:`\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :" +#~ "math:`2\\times 2` matrices." +#~ msgstr "" +#~ "Claramente, la introducción del número imaginario unitario es suficiente " +#~ "para capturar el comportamiento de las matrices de rotación 2D. Como nota " +#~ "al pie de página, mientras que el número :math:`e^{{imath{theta}` sólo " +#~ "puede representar una matriz de rotación, por supuesto no puede " +#~ "representar una matriz arbitraria :math:`2 \\times 2` (lo que significa " +#~ "que no hay escalado, roturas, etc): después de todo, U(1) no es isomorfo " +#~ "para `:math:`\\text{GL}(2, \\mathbb R)`, el grupo de todas las matrices " +#~ "reales (invertibles) de :math:`2\\times 2`." + +#~ msgid "" +#~ "The equivalence of these two seemingly different way of representing " +#~ "vectors and rotations in 2D lies in the `isomorphism between the Lie " +#~ "groups SO(2) and U(1) `_." +#~ msgstr "" +#~ "La equivalencia de estas dos formas aparentemente diferentes de " +#~ "representar vectores y rotaciones en 2D radica en el `isomorfismo entre " +#~ "los grupos de Lie SO(2) y U(1) `_." + +#~ msgid "" +#~ "Furthermore, in this representation, it is clear that you can do a " +#~ "\"smooth\" rotation by slowly changing :math:`\\theta`, which is the 2D " +#~ "analogue of SLERP (could as well be called Circular Linear " +#~ "Interpolation!). Note that if you linearly interpolate the *elements* of " +#~ "two rotation matrices (that is, linearly interpolating between :math:" +#~ "`R_{ij}` and :math:`R'_{ij}` ), you'll get a weird trajectory with jerky " +#~ "motion; to do SLERP with a matrix, you need to extract the angles from " +#~ "each matrix (which can only happen for matrices whose entries have to " +#~ "form given by :math:`R(\\theta)` above; that is, elements of SO(2)), " +#~ "interpolate between the angles linearly, and construct the intermediate " +#~ "matrix using that angle." +#~ msgstr "" +#~ "Además, en esta representación, está claro que se puede hacer una " +#~ "rotación \"suave\" cambiando lentamente :math:`\\theta`, que es el " +#~ "análogo 2D de SLERP (¡también podría llamarse Interpolación Lineal " +#~ "Circular!). Si se interpolan linealmente los *elementos* de dos matrices " +#~ "de rotación (es decir, interpolando linealmente entre :math:`R_{ij}` y :" +#~ "math:`R'_{ij}` ), se obtendrá una trayectoria extraña con un movimiento " +#~ "espasmódico; para hacer SLERP con una matriz, es necesario extraer los " +#~ "ángulos de cada matriz (lo que sólo puede ocurrir para matrices cuyas " +#~ "entradas tienen que formarse por :math:`R(\\theta)` arriba; es decir, " +#~ "elementos de SO(2)), interpolar entre los ángulos linealmente, y " +#~ "construir la matriz intermedia usando ese ángulo." + +#~ msgid "" +#~ "The take-aways of this short visit to the more understandable 2D land are:" +#~ msgstr "" +#~ "Las ventajas más comprensibles de esta breve visita a la tierra 2D son:" + +#~ msgid "" +#~ "There can be different (but \"equivalent\", of course) *representations* " +#~ "of rotations: like matrices and complex numbers." +#~ msgstr "" +#~ "Puede haber diferentes (pero \"equivalentes\", por supuesto) " +#~ "*representaciones* de rotaciones: como matrices y números complejos." + +#~ msgid "" +#~ "Despite the fact that you can use complex numbers to represent vectors " +#~ "and rotations in 2D, the *concept* of rotations in 2D doesn't require an " +#~ "understanding/knowledge of complex numbers or Euler's formula." +#~ msgstr "" +#~ "A pesar de que se pueden usar números complejos para representar vectores " +#~ "y rotaciones en 2D, el *concepto* de rotaciones en 2D no requiere un " +#~ "entendimiento/conocimiento de números complejos o de la fórmula de Euler." + +#~ msgid "" +#~ "The introduction of the imaginary :math:`\\imath` is not black magic: " +#~ "it's just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :" +#~ "math:`1` and :math:`\\imath` behave the same way as :math:`I_2` and :math:" +#~ "`J_z` under multiplication (see the group multiplication table given " +#~ "above)." +#~ msgstr "" +#~ "La introducción del imaginario :math:`\\imath` no es magia negra: es algo " +#~ "que se imita a la matriz de :math:`2 \\times 2` :math:`J_z`: `math:`1` y :" +#~ "math:`\\imath` se comportan de la misma manera que :math:`I_2` and :math:" +#~ "`J_z` en la multiplicación (ver la tabla de multiplicación de grupos " +#~ "mostrada más arriba)." + +#~ msgid "" +#~ "These are often sources of confusion in 3D: introducing a third dimension " +#~ "means we have new rotation axes (rotations around X and Y axes) giving " +#~ "rise to alternative parametrizations (such as Euler angles), and new " +#~ "generators :math:`J_x` and :math:`J_y`, which will be the generalization " +#~ "of :math:`J_z` above." +#~ msgstr "" +#~ "Éstas son a menudo fuentes de confusión en 3D: introducir una tercera " +#~ "dimensión significa que tenemos nuevos ejes de rotación (rotaciones " +#~ "alrededor de los ejes X e Y) dando lugar a parametrizaciones alternativas " +#~ "(como los ángulos de Euler), y nuevos generadores :math:`J_x` y `mateh:" +#~ "`J_y`, que será la generalización de :math:`J_z` arriba." + +#~ msgid "Some mathematical remarks (again, feel free to skip)" +#~ msgstr "" +#~ "Algunos comentarios matemáticos (de nuevo, siéntete libre de omitirlos)" + +#~ msgid "" +#~ "The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :" +#~ "math:`n(n-1)/2` generators. Furthermore, the next step (after " +#~ "quaternions, which is `another accident `_) of `Cayley-Dickson construction " +#~ "`_ " +#~ "does *not* correspond to a Lie algebra, but rather a non-associative " +#~ "algebra called `octonions `_. " +#~ "Rather, in arbitrary dimensions, the \"complex\" representation can be " +#~ "written using the generators of Spin(:math:`n`), which is a double cover " +#~ "of SO(:math:`n`). Also, throughout this page, when we say representation " +#~ "of SO(2), U(1) or any other group, we are talking about the " +#~ "`*fundamental* `_ `irreducible representation `_, corresponding to a " +#~ "`Young diagram `_ with a " +#~ "single box." +#~ msgstr "" +#~ "El hecho de que SO(3) tenga 3 generadores es un accidente: SO(:math:`n`) " +#~ "tiene :math:`n(n-1)/2` generadores. Además, el siguiente paso (después de " +#~ "los cuaternios, que es `otro accidente `_) de `construcción de Cayley-Dickson " +#~ "`_ no " +#~ "corresponde a un álgebra Lie, sino a un álgebra no asociativa llamada " +#~ "`octonions `_. Más bien, en " +#~ "dimensiones arbitrarias, la representación \"compleja\" puede ser escrita " +#~ "usando los generadores de Spin(:math:`n`), que es una doble portada de " +#~ "SO(:math:`n`). Además, a lo largo de esta página, cuando decimos " +#~ "representación de SO(2), U(1) o cualquier otro grupo, estamos hablando de " +#~ "la `*fundamental* `_ `representación irreductible `_, correspondiente a un " +#~ "`Diagrama joven `_ con una " +#~ "sola casilla." + +#~ msgid "Representation of rotations in 3D" +#~ msgstr "Representación de rotaciones en 3D" + +#~ msgid "" +#~ "Let's first review how 3D rotations work using familiar vectors and " +#~ "matrices." +#~ msgstr "" +#~ "Primero repasemos cómo funcionan las rotaciones 3D usando vectores y " +#~ "matrices ya conocidos." + +#~ msgid "" +#~ "In 2D, we considered vectors lying in the :math:`xy` plane, and the only " +#~ "axis we could can rotate them was the :math:`z`-axis. In 3D, we can " +#~ "perform a rotation around any axis. And this doesn't just mean around :" +#~ "math:`x, y, z` axes, the rotation can also be around an axis which is a " +#~ "linear combination of those, where :math:`\\boldsymbol n` is the unit " +#~ "vector (meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) " +#~ "aligned with the axis we want to perform the rotation." +#~ msgstr "" +#~ "En 2D, consideramos vectores que yacen en el plano :math:`xy`, y el único " +#~ "eje que podíamos rotarlos era el eje :math:`z`. En 3D, podemos realizar " +#~ "una rotación alrededor de cualquier eje. Y esto no sólo significa " +#~ "alrededor de los ejes `x, y, z`, la rotación también puede ser alrededor " +#~ "de un eje que es una combinación lineal de ellos, donde :math:`" +#~ "\\boldsymbol n` es el vector unitario (es decir, :math:`\\boldsymbol n " +#~ "\\cdot \\boldsymbol n = 1` ) alineado con el eje que queremos realizar la " +#~ "rotación." + +#~ msgid "" +#~ "Just like the 2D rotation matrix, the 3D rotation matrix can also be " +#~ "derived with some effort by drawing lots of arrows and angles and some " +#~ "linear algebra, but this would be opaque and won't give us much insight " +#~ "to what's going on. A less straightforward, but more rewarding way of " +#~ "deriving this matrix is to understand the rotation group SO(3)." +#~ msgstr "" +#~ "Al igual que la matriz de rotación 2D, la matriz de rotación 3D también " +#~ "puede ser derivada con un poco de esfuerzo dibujando muchas flechas y " +#~ "ángulos y algo de álgebra lineal, pero esto sería opaco y no nos dará " +#~ "mucha información de lo que está pasando. Una forma menos directa, pero " +#~ "más gratificante de derivar esta matriz es entender el grupo de rotación " +#~ "SO(3)." + +#~ msgid "" +#~ "SO(3) is the group of rotations in Euclidean 3D space (for which the " +#~ "`signature `_ is :math:" +#~ "`(+1,+1,+1)`), which preserve the magnitude and handedness of the vectors " +#~ "it acts on. The most typical way to represent its elements is to use :" +#~ "math:`3 \\times 3` real orthogonal matrices with determinant :math:`+1`. " +#~ "This :math:`\\text{Mat}(3, \\mathbb R)` representation is called the " +#~ "fundamental representation of SO(3)." +#~ msgstr "" +#~ "SO(3) es el grupo de rotaciones en el espacio 3D euclidiano (cuya `firma " +#~ "`_ es :math:`(+1,+1," +#~ "+1)`), que conservan la magnitud y procedencia de los vectores sobre los " +#~ "que actúa. La forma más típica de representar sus elementos es usar " +#~ "matrices ortogonales reales de :math:`3 \\times 3` con determinante :math:" +#~ "`+1`. Esta representación se llama la representación fundamental de SO(3)." + +#~ msgid "" +#~ "To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, " +#~ "J_y, J_z` and we found that they can be represented using these :math:" +#~ "`3\\times 3` real matrices:" +#~ msgstr "" +#~ "Para recapitular lo que hablamos antes, SO(3) tiene 3 generadores, :math:" +#~ "`J_x, J_y, J_z` y encontramos que pueden ser representados usando las " +#~ "siguientes :math:`3\\times 3` matrices reales:" + +#~ msgid "" +#~ "These matrices have the same \"multiplication table\" as :math:`J_i` " +#~ "(they're isomorphic), so for all practical purposes, you can replace the " +#~ "operators with their matrix representations." +#~ msgstr "" +#~ "Estos matrices tienen la misma \"tabla de multiplicación\" que :math:" +#~ "`J_i` (son isomórficos), así que para todos los efectos prácticos, puede " +#~ "reemplazar los operadores con sus representaciones matriciales." + +#~ msgid "" +#~ "We also found that an element of SO(3), that is, a rotation operator is" +#~ msgstr "" +#~ "También encontramos que un elemento de SO(3), es decir, un operador de " +#~ "rotación es" + +#~ msgid "" +#~ "If you want, you can plug-in the matrix representations for :math:`J_i` " +#~ "and derive the complicated :math:`3\\times 3` rotation matrix which is" +#~ msgstr "" +#~ "Si quieres, puedes conectar las representaciones de la matriz para :math:" +#~ "`J_i` y derivar la complicada matriz de rotación :math:`3\\times 3 que es" + +#~ msgid "" +#~ "(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot " +#~ "\\boldsymbol J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly " +#~ "evaluate the last term in the Rodrigues' formula, where :math:`\\otimes` " +#~ "is the `Kronecker product `_ which is also called `outer product `_ for vectors. Using the `half-angle " +#~ "formulae `_ to rewrite :math:`" +#~ "\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin\\frac{\\varphi}{2}` " +#~ "and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}{2}` in Rodrigues' " +#~ "formula, you can use cosine and sine terms as a visual aid when comparing " +#~ "to the matrix form.)" +#~ msgstr "" +#~ "(Pista: puedes usar la relación :math:`(\\boldsymbol n \\cdot " +#~ "\\boldsymbol J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` para " +#~ "evaluar rápidamente el último término de la fórmula de Rodrigues, donde :" +#~ "math:`\\otimes` es el `producto de Kronecker `_ que también se llama `producto exterior " +#~ "`_ para reescribir :math:`\\sin\\varphi = 2 \\cos" +#~ "\\frac{\\varphi}{2} \\sin\\frac{\\varphi}{2}` y :math:`1-\\cos\\varphi = " +#~ "2 \\sin^2\\frac{\\varphi}{2}` en la fórmula de Rodrigues, se pueden usar " +#~ "términos de coseno y seno como una ayuda visual cuando se compara con la " +#~ "forma de la matriz.)" + +#~ msgid "" +#~ "However, we don't *have to* use matrices to represent SO(3) generators :" +#~ "math:`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to " +#~ "emulate :math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it " +#~ "turns out we can do something similar here." +#~ msgstr "" +#~ "Sin embargo, no *tenemos que* usar matrices para representar generadores " +#~ "SO(3) :math:`J_i`. ¿Recuerdas cómo usamos :math:`\\imath`, la unidad " +#~ "imaginaria para emular :math:`J_z` en lugar de usar una matriz :math:`2 " +#~ "\\times 2`? Resulta que podemos hacer algo similar aquí." + +#~ msgid "" +#~ "`Hamilton `_ is " +#~ "mostly commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less " +#~ "known contributions is essentially an alternative way of representing 3D " +#~ "cross product, which eventually gave in to popularity of usual vector " +#~ "`cross products `_. " +#~ "He essentially realized that there are three different non-commuting " +#~ "rotations in 3D, and gave a name to the generator for each. He identified " +#~ "the operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y " +#~ "\\times, \\boldsymbol e_z \\times\\}` as the elements of an algebra, " +#~ "naming them as :math:`\\{i,j,k\\}`." +#~ msgstr "" +#~ "`Hamilton `_ es " +#~ "comúnmente conocido por la omnipresente `mecánica Hamiltoniana `_ en física. Una de sus " +#~ "contribuciones menos conocidas es esencialmente una forma alternativa de " +#~ "representar el producto vectorial 3D, que finalmente cedió a la " +#~ "popularidad del vector habitual `productovectorial `_. Esencialmente se dio cuenta de que hay " +#~ "tres rotaciones diferentes no conmutadas en 3D, y le dio un nombre al " +#~ "generador para cada una. Identificó a los operadores :math:`" +#~ "\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, \\boldsymbol e_z " +#~ "\\times\\}` como los elementos de un álgebra, nombrándolos :math:`\\{i,j,k" +#~ "\\}`." + +#~ msgid "" +#~ "This may sound trivial at this point, because we're equipped with all the " +#~ "machinery of Lie groups and Lie algebras: apparently, quaternion units :" +#~ "math:`\\{i,j,k\\}` are just another representation of the SO(3) " +#~ "generators, which satisfy the Lie bracket. Well, no so fast. While the " +#~ "Lie *algebra* :math:`\\mathfrak{so}(3)`, whose elements are the linear " +#~ "combination of :math:`J_i` s are isomorphic to unit quaternions, but " +#~ "quaternions are :math:`1 w + x i + y j + z k` in general, so there's also " +#~ "an identity part, which isn't a vector that is a part of any Lie algebra. " +#~ "Quaternions look more like the *group* SO(3) (when they're normalized, " +#~ "because SO(3) preserves vector norms). But it actually isn't isomorphic " +#~ "to SO(3). It turns out that unit quaternions are isomorphic to the group " +#~ "SU(2) (which is isomorphic to Spin(3)), which in turn is a double cover " +#~ "of SO(3)." +#~ msgstr "" +#~ "Esto puede sonar trivial en este punto, porque estamos equipados con toda " +#~ "la maquinaria de los grupos y algebras de Lie: aparentemente, las " +#~ "unidades de cuaterniones :math:`\\{i,j,k\\}` son sólo otra representación " +#~ "de los generadores de SO(3), que satisfacen el soporte de Lie. Bueno, no " +#~ "tan rápido. Mientras que el *álgebra* de la Lie :math:`\\mathfrak{so}" +#~ "(3)`, cuyos elementos son la combinación lineal de :math:`J_i` s son " +#~ "isomórficos a los cuaterniones unitarios, pero los cuaterniones son :math:" +#~ "`1 w + x i + y j + z k` en general, así que también hay una parte de " +#~ "identidad, que no es un vector que es parte de cualquier álgebra de Lie. " +#~ "Las cuartniones se parecen más al *grupo* SO(3) (cuando están " +#~ "normalizados, porque el SO(3) preserva las normas vectoriales). Pero en " +#~ "realidad no es isomorfo al SO(3). Resulta que los cuaterniones unitarios " +#~ "son isomórficos al grupo SU(2) (que es isomórfico a Spin(3)), que a su " +#~ "vez es una doble cobertura de SO(3)." + +#~ msgid "" +#~ "SU(2) is essentially the group of unitary rotations with determinant +1 " +#~ "(called Special Unitary groups) which preserve the norm of complex " +#~ "vectors it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` " +#~ "correspond to :math:`\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/" +#~ "\\imath`. To exemplify, :math:`R = e^{\\varphi \\boldsymbol n \\cdot " +#~ "\\boldsymbol J} \\in \\text{SO}(3)` rotates a real vector by :math:`R " +#~ "\\boldsymbol v` and the corresponding rotation :math:`U = e^{-\\imath" +#~ "\\varphi \\boldsymbol n \\cdot \\boldsymbol \\sigma/2} \\in \\text{SU}" +#~ "(2)` rotates the same vector through :math:`U (\\boldsymbol v \\cdot " +#~ "\\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U \\to -U` achieves " +#~ "the same SO(3) rotation, SU(2) it's said to be a double cover of SO(3) " +#~ "(this is mapping gives the adjoint representation of SU(2) by the way). " +#~ "Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " +#~ "\\sigma_y, \\sigma_z) \\cong (i,j,k)`." +#~ msgstr "" +#~ "SU(2) es esencialmente el grupo de rotaciones unitarias con determinante " +#~ "+1 (llamados grupos unitarios especiales) que preservan la norma de los " +#~ "vectores complejos sobre los que actúa, generados por `Matrices de Pauli " +#~ "`_ :math:`\\sigma_i` y :" +#~ "math:`i,j,k`corresponde a :math:`\\sigma_x/\\imath\\ \\sigma_y/\\imath, " +#~ "\\sigma_z/\\imath`. Para ejemplificar, :math:`R = e^{\\varphi " +#~ "\\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}(3)` rota un vector " +#~ "real por :math:`R \\boldsymbol v` y la rotación correspondiente :math:`U " +#~ "= e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol \\sigma/2} \\in " +#~ "\\text{SU}(2)` rota el mismo vector a través de :math:`U (\\boldsymbol v " +#~ "\\cdot \\boldsymbol \\sigma) U^\\dagger`. Hay que tener en cuenta que :" +#~ "math:`U \\to -U` logra la misma rotación de SO(3), SU(2) se dice que es " +#~ "una cubierta doble de SO(3) (este mapeo da la representación adjunta de " +#~ "SU(2)). Aquí :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " +#~ "\\sigma_y, \\sigma_z) \\cong (i,j,k)`." + +#~ msgid "" +#~ "SU(2) and SO(3) look the same locally (their tangent spaces dictated by " +#~ "their Lie algebras are isomorphic), but they're different globally. While " +#~ "this sounds like just a technicality, this has topological implications, " +#~ "but we won't get into that much. The take away from this discussion is " +#~ "that unit quaternions *can* be used emulate SO(3) rotations." +#~ msgstr "" +#~ "SU(2) y SO(3) se ven iguales localmente (sus espacios tangenciales " +#~ "dictados por sus algebras de Lie son isomórficos), pero son diferentes " +#~ "globalmente. Aunque esto suena como un tecnicismo, tiene implicaciones " +#~ "topológicas, pero no vamos a entrar en detalles. La ventaja de esta " +#~ "discusión es que los cuaterniones de la unidad *pueden* utilizarse para " +#~ "emular las rotaciones SO(3)." + +#~ msgid "" +#~ "But taking a step back, why do we bother *emulating* SO(3) at all? For " +#~ "computational purposes, we already have something that works: the matrix " +#~ "representation. Why do we need to both with a weird group that isn't even " +#~ "exactly the same as SO(3)?" +#~ msgstr "" +#~ "Pero dando un paso atrás, ¿por qué nos molestamos en *emular* SO(3)? Para " +#~ "fines computacionales, ya tenemos algo que funciona: la representación " +#~ "matricial. ¿Por qué necesitamos ambos con un grupo raro que ni siquiera " +#~ "es exactamente lo mismo que SO(3)?" + +#~ msgid "" +#~ "The answer is the cost of computation, and this is two fold. First, you " +#~ "see, a rotation operator has only 3 degrees of freedom: two for the unit " +#~ "vector which is the rotation axis, and one for the rotation angle around " +#~ "that axis. A :math:`3\\times 3` matrix, on the other hand has 9 elements. " +#~ "It's an overkill. For example, whenever you multiply two rotations, you " +#~ "need to multiply two :math:`3\\times 3` matrices, summing and multiplying " +#~ "every single element. In terms of CPU cycles, this is wasted effort and " +#~ "we can be more optimal. Second part is precision errors. The errors are " +#~ "worse in matrix representation, because originally, we have only 3 " +#~ "degrees of freedom, which means we can have precision errors in axis and " +#~ "angle (only 3 errors) but it's still an element of SO(3), whereas with " +#~ "matrices, we can have errors in any one of the 9 elements in the matrix " +#~ "and so we can even have a matrix that isn't even an element of SO(3). " +#~ "These errors can quickly build up quickly especially if you're for " +#~ "example modifying the orientation of an object every frame by doing a " +#~ "smooth interpolation between an initial and a target orientation " +#~ "(discussed further in SLERP section)." +#~ msgstr "" +#~ "La respuesta es el costo de la computación, y esto es doble. Primero, un " +#~ "operador de rotación tiene sólo 3 grados de libertad: dos para el vector " +#~ "unitario que es el eje de rotación, y uno para el ángulo de rotación " +#~ "alrededor de ese eje. Una :math:`3\\times 3`, por otro lado tiene 9 " +#~ "elementos. Es una exageración. Por ejemplo, siempre que multipliques dos " +#~ "rotaciones, necesitas multiplicar dos matrices :math:`3\\times 3`, " +#~ "sumando y multiplicando cada elemento. En términos de ciclos de CPU, esto " +#~ "es un esfuerzo desperdiciado y podemos ser más óptimos. La segunda parte " +#~ "son los errores de precisión. Los errores son peores en la representación " +#~ "matricial, porque originalmente, sólo tenemos 3 grados de libertad, lo " +#~ "que significa que podemos tener errores de precisión en el eje y el " +#~ "ángulo (sólo 3 errores), pero sigue siendo un elemento de SO(3), mientras " +#~ "que con las matrices, podemos tener errores en cualquiera de los 9 " +#~ "elementos de la matriz y así incluso podemos tener una matriz que ni " +#~ "siquiera es un elemento de SO(3). Estos errores pueden acumularse " +#~ "rápidamente, especialmente si, por ejemplo, está modificando la " +#~ "orientación de un objeto en cada fotograma haciendo una interpolación " +#~ "suave entre una orientación inicial y una orientación objetivo (discutida " +#~ "más adelante en la sección SLERP)." + +#~ msgid "" +#~ "Sure, we know that elements of SO(3) can be represented by using " +#~ "orthogonal matrices with determinant +1 (hence the name Special " +#~ "Orthogonal) such that :math:`R R^T = I`; in plain language, this means " +#~ "the columns of :math:`R` form an orthonormal set of vectors, so we can " +#~ "eliminate the errors if we perform `Gram-Schmidt `_ orthonormalization once in a " +#~ "while, and force it back into SO(3), such that it's an actual rotation " +#~ "matrix (albeit still noisy in axis and angle). But this is expensive and " +#~ "still quite bad in terms of errors." +#~ msgstr "" +#~ "Claro, sabemos que los elementos de SO(3) pueden ser representados usando " +#~ "matrices ortogonales con determinante +1 (de ahí el nombre Ortogonal " +#~ "Especial) de tal manera que :math:`R R^T = I`; en lenguaje sencillo, " +#~ "esto significa que las columnas de :math:`R` forman un conjunto " +#~ "ortonormal de vectores, por lo que podemos eliminar los errores si " +#~ "realizamos `Gram-Schmidt `_ orthonormalization de " +#~ "vez en cuando, y forzarlo a volver a SO(3), de tal forma que sea una " +#~ "matriz de rotación real (aunque todavía muy ruidosa en el eje y el " +#~ "ángulo). Pero esto es costoso y bastante malo en términos de posibles " +#~ "errores." + +#~ msgid "" +#~ "So, what is the alternative then? Shall we go back to the Rodrigues' " +#~ "formula and hardcode the behavior of :math:`J_i` into our program? A " +#~ "nicer alternative is, we use SU(2) (which we know covers SO(3), twice in " +#~ "fact!), because the equivalent of the Rodrigues' formula is much simpler:" +#~ msgstr "" +#~ "Entonces, ¿cuál es la alternativa? ¿Volvemos a la fórmula de Rodrigues y " +#~ "codificamos el comportamiento de :math:`J_i` en nuestro programa? Una " +#~ "alternativa más agradable es, utilizar SU(2) (que sabemos cubre SO(3), " +#~ "¡dos veces de hecho!), porque el equivalente de la fórmula de Rodrigues " +#~ "es mucho más simple:" + +#~ msgid "" +#~ "owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " +#~ "\\sigma)^2 = I` (something like this happens only at the third power with " +#~ "SO(3) generators, remember? and it doesn't give identity), or if you " +#~ "prefer quaternion version which is more commonly used to represent the " +#~ "isomorphic group Spin(3), this is" +#~ msgstr "" +#~ "gracias a la buena relación :math:`(\\boldsymbol n \\cdot \\boldsymbol " +#~ "\\sigma)^2 = I` (algo así ocurre sólo en la tercera potencia con " +#~ "generadores SO(3), ¿recuerdas? y no nos da la identidad), o si prefieres " +#~ "la versión de cuaternión que se usa más comúnmente para representar al " +#~ "grupo isomórfico Spin(3), ésta es" + +#~ msgid "" +#~ "In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " +#~ "n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " +#~ "azimuthal and polar angles parametrizing the unit vector :math:`" +#~ "\\boldsymbol n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, " +#~ "q_y, q_z) \\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} " +#~ "n_x, \\sin\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such " +#~ "that :math:`U = \\boldsymbol q \\cdot (1, i, j, k)`, and enforce the " +#~ "condition :math:`|\\boldsymbol q|=1` once in a while by renormalization " +#~ "(note that while you can see many people referring to :math:`\\boldsymbol " +#~ "q` as a quaternion, it's not; :math:`U` is the actual quaternion here " +#~ "and :math:`\\boldsymbol q` is just an artificial vector containing the " +#~ "coefficients in the expansion of the exponential map). Of course, if they " +#~ "store :math:`(\\varphi, \\phi, \\theta)`, there is no need for a " +#~ "renormalization because such parametrization guarantees the " +#~ "normalization, but this choice would come at the cost of calculating a " +#~ "bunch of sines and cosines whenever you use them, so this is a middle " +#~ "ground in terms of errors and speed." +#~ msgstr "" +#~ "En los motores de juego, en lugar de almacenar el ángulo del eje :math:" +#~ "`(\\boldsymbol n(\\phi,\\theta), \\varphi )`par donde :math:`\\phi," +#~ "\\theta`son los ángulos acimut y polar que parametrizan el vector " +#~ "unitario :math:`\\boldsymbol n`, la gente normalmente almacena :math:`" +#~ "\\boldsymbol q= (q_0, q_x, q_y, q_z) \\equiv (\\cos\\frac{\\varphi}{2}, " +#~ "\\sin\\frac{\\varphi}{2} n_x, \\sin\\frac{\\varphi}{2} n_y, \\sin" +#~ "\\frac{\\varphi}{2} n_z)` such that :math:`U = \\boldsymbol q \\cdot (1, " +#~ "i, j, k), para hacer cumplir la condición :math:`|\\boldsymbol q|=1` de " +#~ "vez en cuando por renormalización (nota que si bien puedes ver a muchas " +#~ "personas refiriéndose a :math:`\\boldsymbol q` como un cuaternión, no lo " +#~ "es; :math:`U` es el cuaternión real aquí y :math:`\\boldsymbol q` es sólo " +#~ "un vector artificial que contiene los coeficientes en la expansión del " +#~ "mapa exponencial). Por supuesto, si almacenan :math:`(\\varphi, \\phi, " +#~ "\\theta)`, no hay necesidad de una renormalización porque tal " +#~ "parametrización garantiza la normalización, pero esta elección vendría a " +#~ "costa de calcular un montón de senos y cosenos cada vez que se utilizan, " +#~ "por lo que este es un término medio en términos de errores y velocidad." + +#~ msgid "So, the take aways of this section are:" +#~ msgstr "Así que, las ventajas de esta sección son:" + +#~ msgid "" +#~ "Matrices can represent SO(3) just fine, but are a little too general and " +#~ "extravagant in terms of CPU cycles and behave bad in the presence of " +#~ "floating point errors, and errors can even lead to a matrix that doesn't " +#~ "correspond to a rotation matrix at all!" +#~ msgstr "" +#~ "Las matrices pueden representar SO(3) muy bien, pero son demasiado " +#~ "generales y extravagantes en términos de ciclos de CPU y se comportan mal " +#~ "en presencia de errores de coma flotante ¡y los errores pueden incluso " +#~ "llevar a una matriz que no corresponde en absoluto a una matriz de " +#~ "rotación!" + +#~ msgid "" +#~ "For all practical purposes, we can use an element of SU(2) to represent " +#~ "an SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " +#~ "anything in doing so. The main reason for choosing one over another is " +#~ "the SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " +#~ "expansion is neat, clean and simple to work with." +#~ msgstr "" +#~ "A todos los efectos prácticos, podemos utilizar un elemento de SU(2) para " +#~ "representar una rotación SO(3). Es una doble cobertura de SO(3), así que " +#~ "no estaríamos perdiendo nada al hacerlo. La razón principal para elegir " +#~ "uno sobre el otro es que la fórmula de Rodrigues SO(3) es un poco " +#~ "incómoda para trabajar, mientras que la expansión de SU(2) es clara, " +#~ "limpia y fácil de utilizar." + +#~ msgid "" +#~ "Using matrices, you can practically do everything you do with " +#~ "quaternions, vice versa. The real differences, as highlighted, are in " +#~ "computation trade-offs, not mathematics." +#~ msgstr "" +#~ "Usando matrices, prácticamente se puede hacer todo lo que se hace con los " +#~ "cuaterniones, y viceversa. Las diferencias reales, como se ha destacado, " +#~ "están en las compensaciones de cálculo, no en las matemáticas." + +#~ msgid "" +#~ "The relationship between quaternions and 3D rotation matrices is the " +#~ "roughly the same as the relation between the complex number :math:" +#~ "`e^{\\imath\\theta}` and a 2D rotation matrix. Just as the complex " +#~ "number :math:`\\imath \\cong J_z` rotates by :math:`\\pi/2` (which is, as " +#~ "we saw, what a *generator* does), :math:`i,j,k` (which are :math:`\\cong " +#~ "J_x, J_y, J_z`) rotate by :math:`\\pi/2` around :math:`x, y, z` axes; " +#~ "they don't commute with each other because in 3D, the order of rotations " +#~ "is important. Owing to this isomorphism between their generators, an " +#~ "SO(3) rotation :math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}` " +#~ "corresponds to the SU(2) rotation :math:`e^{\\varphi \\boldsymbol n " +#~ "\\cdot (i,j,k)/2}`. This is a helpful picture to gain an intuition on " +#~ "quaternions. While the SO(3) is familiar to many people, the " +#~ "\"Rodrigues' formula\" for the SU(2) one is much preferable graphics " +#~ "programming due to it's simplicity, and hence you see quaternions in game " +#~ "engines." +#~ msgstr "" +#~ "La relación entre los cuaterniones y las matrices de rotación 3D es " +#~ "aproximadamente la misma que la relación entre el número complejo :math:" +#~ "`e^{\\imath\\theta}` y una matriz de rotación 2D. Así como el complejo " +#~ "número :math:`\\imath \\cong J_z` rota por :math:`\\pi/2` (que es, como " +#~ "vimos, lo que hace un *generador*), :math:`i,j,k` (que son :math:`\\cong " +#~ "J_x, J_y, J_z`) rotar por :math:`\\pi/2` alrededor de los ejes :math:`x, " +#~ "y, z`; no se conmutan entre sí porque en 3D, el orden de las rotaciones " +#~ "es importante. Debido a este isomorfismo entre sus generadores, una " +#~ "rotación SO(3) :math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}` " +#~ "corresponde a la rotación SU(2) :math:`e^{\\varphi \\boldsymbol n \\cdot " +#~ "(i,j,k)/2}`. Esta es una imagen útil para tener una idea sobre los " +#~ "cuaterniones. Mientras que el SO(3) es familiar para mucha gente, la " +#~ "\"fórmula de Rodrigues\" para el SU(2) es mucho más recomendable para la " +#~ "programación de gráficos debido a su simplicidad, y por lo tanto se ven " +#~ "cuaterniones en los motores de juego." + +#~ msgid "" +#~ "This doesn't mean quaternions are a generalization of complex numbers in " +#~ "our construction when considering rotations in a strict sense; they're " +#~ "rather the 3D generalization of the 2D rotation generator in some loose " +#~ "sense (loose, because SO(3) and SU(2) are different groups). There *is* a " +#~ "construction which generalizes real numbers to complex numbers to " +#~ "quaternions, called `Cayley-Dickson construction `_, but it's next steps give " +#~ "off topic objects octonions and sedenions (setting exceptional Lie groups " +#~ "aside for octonions)." +#~ msgstr "" +#~ "Esto no significa que los cuaterniones son una generalización de números " +#~ "complejos en nuestra construcción cuando consideramos las rotaciones en " +#~ "un sentido estricto; son más bien la generalización 3D del generador de " +#~ "rotación 2D en un sentido suelto (suelto, porque SO(3) y SU(2) son grupos " +#~ "diferentes). Hay una construcción que generaliza números reales a números " +#~ "complejos a cuaterniones, llamada `Construcción de Cayley-Dickson " +#~ "`_, " +#~ "pero son los siguientes pasos los que producen los objetos tópicos " +#~ "octiones y sedeniones (reservando grupos de Lie excepcionales para " +#~ "octoniones)." + +#~ msgid "" +#~ "Note that we haven't said a word about Euler angles. In both matrix and " +#~ "quaternion *representations*, we sticked to the axis-angle " +#~ "*parametrization*. We will discuss different parametrizations in what " +#~ "follows." +#~ msgstr "" +#~ "Nota que no hemos dicho una sola palabra sobre los ángulos de Euler. " +#~ "Tanto en las *representaciones* de la matriz como en las de los " +#~ "cuaterniones, nos ceñimos a la *parametrización* del ángulo del eje. " +#~ "Analizaremos diferentes parametrizaciones más adelante." + +#~ msgid "Matrix representation of SO(3)" +#~ msgstr "Representación de la matriz de SO(3)" + +#~ msgid "Quaternion representation of SU(2)" +#~ msgstr "Representación por cuaterniones de SU(2)" + +#~ msgid ":math:`(x,y,z)`" +#~ msgstr ":math:`(x,y,z)`" + +#~ msgid "" +#~ ":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" +#~ "\\frac{\\theta}{2})`" +#~ msgstr "" +#~ ":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" +#~ "\\frac{\\theta}{2})`" + +#~ msgid "" +#~ "Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " +#~ "\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" +#~ msgstr "" +#~ "Matrices para :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " +#~ "\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" + +#~ msgid ":math:`i,j,k`" +#~ msgstr ":math:`i,j,k`" + +#~ msgid "" +#~ ":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand " +#~ "with Rodrigues' formula" +#~ msgstr "" +#~ ":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, puede " +#~ "expandirse con la fórmula de Rodrigues" + +#~ msgid "" +#~ ":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with " +#~ "SU(2) \"Rodrigues' formula\"" +#~ msgstr "" +#~ ":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` puede expandirse con " +#~ "la fórmula de Rodrigues SU(2)" + +#~ msgid "" +#~ "Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding " +#~ "to :math:`x,y,z`." +#~ msgstr "" +#~ "En el ejemplo anterior, :math:`r,\\theta,\\phi` son coordenadas esféricas " +#~ "correspondientes a :math:`x,y,z`." + +#~ msgid "A note about the SU(2) vector" +#~ msgstr "Una nota sobre el vector SU(2)" + +#~ msgid "" +#~ "We earlier mentioned that rotation of a real vector in SU(2) is done via :" +#~ "math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " +#~ "\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what " +#~ "the complex vector listed above :math:`|\\psi\\rangle = (\\cos" +#~ "\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do " +#~ "with that. The answer is, there vector :math:`|\\psi\\rangle` is the one " +#~ "a single :math:`U` acts on, and in terms of it, we can rewrite :math:`U " +#~ "(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|" +#~ "\\psi\\rangle \\otimes \\langle \\psi|) U^\\dagger` up to some trivial " +#~ "identity term, where :math:`\\langle \\psi| = |\\psi\\rangle^\\dagger` " +#~ "(this is the way complex vectors are typically denoted in quantum " +#~ "mechanics and is called `bra-ket notation `_: bra is like the vector and ket is the " +#~ "`conjugate transpose `_, " +#~ "and people typically omit the :math:`\\otimes` in between because that's " +#~ "already implied when you multiply a ket with a bra, and likewise there is " +#~ "no :math:`\\cdot` when you multiply a bra with ket since that's also " +#~ "implied)." +#~ msgstr "" +#~ "Anteriormente mencionamos que la rotación de un vector real en SU(2) se " +#~ "realiza a través de :math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma " +#~ "= U (\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`, y puede que " +#~ "te estés preguntando qué tiene que ver el vector complejo :math:`|\\psi" +#~ "\\rangle = (\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" +#~ "\\frac{\\theta}{2})` mencionado anteriormente con esto. La respuesta es, " +#~ "que hay un vector :math:`|\\psi\\rangle` is the one a single :math:`U` " +#~ "que actúa, y en términos de esto, podemos reescribir :math:`U " +#~ "(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger` como :math:`r U " +#~ "(|\\psi\\rangle \\otimes \\langle \\psi|) U^\\dagger` hasta algún término " +#~ "de identidad trivial, donde :math:`\\langle \\psi| = |\\psi\\rangle^" +#~ "\\dagger` (esta es la forma en que los vectores complejos son típicamente " +#~ "denotados en la mecánica cuántica y se llama `Notación bra-ket `_: el bra es como el vector " +#~ "y el ket es el `operador adjunto `_, y la gente típicamente omite el :math:`\\otimes` " +#~ "entremedio porque eso ya está implícito cuando multiplicas un ket por un " +#~ "bra, y de la misma manera no hay :math:`\\cdot` cuando multiplicas un bra " +#~ "por un ket ya que eso también está implícito)." + +#~ msgid "" +#~ "So, notational concerns aside, long story short, the vector listed above " +#~ "is in a generalized sense \"half\" of what we are rotating:" +#~ msgstr "" +#~ "Por lo tanto, dejando a un lado las preocupaciones notacionales, " +#~ "resumiendo, el vector mencionado anteriormente es, en un sentido " +#~ "generalizado, \"la mitad\" de lo que estamos rotando:" + +#~ msgid "" +#~ "and each \"half\" goes to one of the :math:`U` s on each side of the " +#~ "modified/generalized relation" +#~ msgstr "" +#~ "y cada \"mitad\" va a una de las :math:`U` s a cada lado de la relación " +#~ "modificada/generalizada" + +#~ msgid "" +#~ "so everything is compatible, and :math:`|\\psi'\\rangle = U |" +#~ "\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " +#~ "satisfied. This parametrization of an SU(2) vector is typically done in " +#~ "spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because " +#~ "state vectors are normalized in quantum mechanics), and the sphere is " +#~ "called `Bloch sphere `_)." +#~ msgstr "" +#~ "así que todo es compatible, y :math:`|\\psi'\\rangle = U |" +#~ "\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` es " +#~ "satisfactorio. Esta parametrización de un vector SU(2) se hace " +#~ "típicamente en coordenadas esféricas :math:`\\theta,\\phi` (para :math:" +#~ "`r=1`, porque los vectores de estado están normalizados en la mecánica " +#~ "cuántica), y la esfera se llama `Esfera de Bloch `_)." + +#~ msgid "Parametrization of rotations" +#~ msgstr "Parametrización de rotaciones" + +#~ msgid "" +#~ "From general arguments of linear independence, it is clear that a general " +#~ "rotation in 3D requires 3 independent parameters, which is known as " +#~ "`Euler's rotation theorem `_. It is tempting to think rotations as three-" +#~ "dimensional vectors, but they are rather `linear operators `_ that transform vectors." +#~ msgstr "" +#~ "A partir de argumentos generales de independencia lineal, está claro que " +#~ "una rotación general en 3D requiere 3 parámetros independientes, lo que " +#~ "se conoce como `Teorema de rotación de Euler `_ que " +#~ "transforman los vectores." + +#~ msgid "" +#~ "There are `different ways of parametrizing rotations `_ in the `3D " +#~ "Euclidean space `_ using 3 " +#~ "parameters, and we will go through the two commonly used in game " +#~ "programming." +#~ msgstr "" +#~ "Hay `diferentes formas de parametrizar rotaciones `_ en el `espacio euclídeo 3D " +#~ "`_ usando 3 " +#~ "parámetros, y pasaremos por los dos más comunes en la programación de " +#~ "juegos." + +#~ msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" +#~ msgstr "Parametrización del eje-ángulo: :math:`(\\phi, \\theta, \\varphi)`" + +#~ msgid "" +#~ "As we found out, this is the *de facto* parametrization of rotations in " +#~ "3D (or in fact, in any dimensions), which is also the direct " +#~ "generalization of rotations in 2D, is this: choose an axis in 3D space (a " +#~ "unit vector to specify a direction, which has two independent parameters, " +#~ "because its length is conventionally fixed to 1) and is typically " +#~ "parametrized using `polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi," +#~ "\\theta) = (\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos" +#~ "\\theta)` and specify the angle of rotation around that axis :math:`" +#~ "\\varphi` (which is the third parameter) whose sense of rotation is fixed " +#~ "by the `right-hand rule `_ " +#~ "(for a right-hand coordinate system). For (embedded) 2D rotations in the :" +#~ "math:`xy`-plane, the rotation axis is taken to be the z-axis, and we only " +#~ "need to specify the rotation angle. In 3D, the rotation axis can be " +#~ "pointing toward any direction (since the axis is a unit vector, you can " +#~ "think of it as a point on the unit sphere, if you like). This way of " +#~ "parametrizing rotations is called axis-angle parametrization, and is the " +#~ "easiest to picture intuitively." +#~ msgstr "" +#~ "Como hemos descubierto, se trata *de la* parametrización de las " +#~ "rotaciones en 3D (o de hecho, en cualquier dimensión), que es también la " +#~ "generalización directa de las rotaciones en 2D, es esto: elegir un eje en " +#~ "el espacio 3D (un vector unitario para especificar una dirección, que " +#~ "tiene dos parámetros independientes, ya que su longitud se fija " +#~ "convencionalmente a 1) y es típicamente parametrizada utilizando `polar " +#~ "and azimuthal angles `_ como :math:`\\boldsymbol n(\\phi,\\theta) " +#~ "= (\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` y " +#~ "especificar el ángulo de rotación alrededor de ese eje :math:`\\varphi` " +#~ "(que es el tercer parámetro) cuyo sentido de rotación está fijado por la " +#~ "`regla de la mano derecha `_ (para un sistema de coordenadas a la " +#~ "derecha). Para rotaciones 2D (incrustadas) en el plano :math:`xy`, el eje " +#~ "de rotación se toma como el eje z, y sólo necesitamos especificar el " +#~ "ángulo de rotación. En 3D, el eje de rotación puede estar apuntando hacia " +#~ "cualquier dirección (ya que el eje es un vector unitario, puedes pensar " +#~ "en él como un punto en la esfera unitaria, si quieres). Esta forma de " +#~ "parametrizar las rotaciones se llama parametrización eje-ángulo, y es la " +#~ "más fácil de visualizar de forma intuitiva." + +#~ msgid "" +#~ "Another advantage of the axis angle parametrization is, it is easy to " +#~ "interpolate between two different rotations (let's call their parameters :" +#~ "math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " +#~ "\\varphi_2`), which is useful when you're changing the orientation of an " +#~ "object, starting from a given initial orientation and going toward a " +#~ "final one. A nice way of doing this is described in a later section where " +#~ "we describe SLERP. It results in a smooth motion, rather than a \"jerky\" " +#~ "motion which may start fast, go slow in the middle and go fast again etc. " +#~ "It turns out that if a mass is transported this way, it experiences the " +#~ "least amount of torque (compared to other possible trajectories). This " +#~ "way of linearly interpolating rotations in the axis-angle parametrization " +#~ "is called Spherical Linear Interpolation or SLERP, and is almost " +#~ "ubiquitously used in games." +#~ msgstr "" +#~ "Otra ventaja de la parametrización del ángulo del eje es que es fácil " +#~ "interpolar entre dos rotaciones diferentes (llamemos a sus parámetros :" +#~ "math:`\\boldsymbol n_1, \\varphi_1` y :math:`\\boldsymbol n_2, " +#~ "\\varphi_2`), lo cual es útil cuando se está cambiando la orientación de " +#~ "un objeto, comenzando desde una orientación inicial dada y yendo hacia " +#~ "una final. Una buena manera de hacer esto se describe en una sección " +#~ "posterior donde describimos SLERP. El resultado es un movimiento suave, " +#~ "en lugar de un movimiento \"brusco\" que puede empezar rápido, ir lento " +#~ "en el medio y volver a ir rápido, etc. Resulta que si una masa se " +#~ "transporta de esta manera, experimenta la menor cantidad de torsión (en " +#~ "comparación con otras trayectorias posibles). Esta forma de interpolar " +#~ "linealmente las rotaciones en la parametrización eje-ángulo se llama " +#~ "Interpolación Lineal Esférica o SLERP, y es casi omnipresente en los " +#~ "juegos." + +#~ msgid "" +#~ "Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " +#~ "\\varphi_3 )`" +#~ msgstr "" +#~ "Ángulos de Euler (y ángulos Tait-Bryan): :math:`(\\varphi_1, \\varphi_2, " +#~ "\\varphi_3 )`" + +#~ msgid "" +#~ "Another way of parametrizing 3D rotations is by considering a sequence of " +#~ "at least 3 rotations around certain, fixed axes. This could be, for " +#~ "example \"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then " +#~ "rotate around the :math:`Y`-axis by :math:`\\varphi_2`, and finally " +#~ "rotate around the :math:`x`-axis by :math:`\\varphi_3`\". Of course, " +#~ "these axes don't have to be Z, then Y, then X. As long as two sequential " +#~ "rotations are not around the same axis (in which case they would combine " +#~ "into a single rotation, hence reducing the number of actually independent " +#~ "parameters by 1), they can be anything. They don't even need to be " +#~ "aligned with any \"named\" axis. Another thing important think to watch " +#~ "out is, if you imagine that there is a local coordinate system \"painted" +#~ "\" on the object, as you go through the 3-step rotation sequence, that " +#~ "local frame rotates with the object itself, while the global frame of " +#~ "course remains as-is. The rotation angles specified with respect to a " +#~ "global, fixed reference frame are sometimes called Tait-Bryan angles. So " +#~ "when we're specifying a general rotation in terms of 3 rotations around " +#~ "certain \"fixed\" axes, you need to specify whether those axes refer to " +#~ "the global (called extrinsic, usually written with an additional prime, :" +#~ "math:`X'` rather than :math:`X`, after each rotation ) or the local " +#~ "(called intrinsic) frame as well. Typically, extrinsic is used as it is " +#~ "relatively easier to picture, and axes are chosen to coincide with X,Y or " +#~ "Z. The 3 rotation angles used in such representation of rotations is " +#~ "called Euler angles." +#~ msgstr "" +#~ "Otra forma de parametrizar rotaciones 3D es considerando una secuencia de " +#~ "al menos 3 rotaciones alrededor de ciertos ejes fijos. Esto podría ser, " +#~ "por ejemplo, \"rotar alrededor del eje :math:`Z por `math:``varphi_1`, " +#~ "luego rotar alrededor del eje ``Y`` por `math:``varphi_2``, y finalmente " +#~ "rotar alrededor del eje :math:`x` por ``math:`\\varphi_3``\". Por " +#~ "supuesto, estos ejes no tienen que ser Z, luego Y, luego X. Mientras dos " +#~ "rotaciones secuenciales no estén alrededor del mismo eje (en cuyo caso se " +#~ "combinarían en una sola rotación, reduciendo así el número de parámetros " +#~ "realmente independientes en 1), pueden ser cualquier cosa. Ni siquiera " +#~ "necesitan estar alineados con ningún eje \"nominal\". Otra cosa " +#~ "importante que hay que tener en cuenta es, si se imagina que hay un " +#~ "sistema de coordenadas local \"pintado\" en el objeto, a medida que pasa " +#~ "por la secuencia de rotación de 3 pasos, que el marco local gira con el " +#~ "objeto en sí, mientras que el marco global, por supuesto, permanece como " +#~ "está. Los ángulos de rotación especificados con respecto a un marco de " +#~ "referencia global y fijo se denominan a veces ángulos de Tait-Bryan. Así " +#~ "que cuando estamos especificando una rotación general en términos de 3 " +#~ "rotaciones alrededor de ciertos ejes \"fijos\", necesitamos especificar " +#~ "si esos ejes se refieren al global (llamado extrínseco, usualmente " +#~ "escrito con un primo adicional, :math:`X'` en lugar de :math:`X`, después " +#~ "de cada rotación) o también al marco local (llamado intrínseco). " +#~ "Típicamente, se utiliza extrínseco, ya que es más fácil de visualizar, y " +#~ "los ejes se eligen para que coincidan con X, Y o Z. Los 3 ángulos de " +#~ "rotación utilizados en esta representación de las rotaciones se llaman " +#~ "ángulos de Euler." + +#~ msgid "" +#~ "Ancient mechanical devices called gimbal (which are long obsolete in this " +#~ "age) used to calculate realize 3D rotations in engineering applications " +#~ "in vehicles increased the popularity of Euler angles. Furthermore, since " +#~ "the :math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to " +#~ "write down, it is commonly said that Euler angles are easier to " +#~ "understand when compared to axis-angle representation (which is commonly, " +#~ "although not necessarily, implemented through quaternions). While this " +#~ "may be true if you're creating a linear algebra library from scratch, or " +#~ "filling in the elements of the transformation matrix on your own, this is " +#~ "not the case when writing games with game engines, such as Godot. The " +#~ "popularity of Euler angles endured despite the fact that they, in fact, " +#~ "can not represent a smooth transition between two different rotations by " +#~ "a smooth variation of the three angles. The reason behind this lies in " +#~ "the fact that Euler angles describe a chart on 3-torus, which is not a " +#~ "`covering map `_ of SO(3), " +#~ "three dimensional rotations (if this sounds too abstract, see the " +#~ "subsection about 3-torus and sphere below). As the mapping from Euler " +#~ "angles to SO(3) is ill-defined at certain points, during the smooth " +#~ "interpolation between two rotations, we may bump into such points, and as " +#~ "a result the rank may drop to 2 or even 1 (which mechanically corresponds " +#~ "to a situation in which two or three gimbals become aligned as they go " +#~ "around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler angles to " +#~ "represent a fixed rotation, they're not suitable for slowly changing the " +#~ "orientation of objects. You can still do that if you put some additional " +#~ "effort to avoid gimbal-lock, of course, but even if by some luck you " +#~ "don't bump into such bad points, a linear interpolation between two sets " +#~ "of Euler angles is going to result in a \"jerky\" motion." +#~ msgstr "" +#~ "Antiguos dispositivos mecánicos llamados cardanes (que son obsoletos " +#~ "desde hace mucho tiempo en esta era) utilizados para calcular las " +#~ "rotaciones 3D en aplicaciones de ingeniería en vehículos aumentaron la " +#~ "popularidad de los ángulos de Euler. Además, dado que la matriz de " +#~ "rotación de :math:`3 \\times 3` alrededor del eje X,Y o Z es más fácil de " +#~ "escribir, comúnmente se dice que los ángulos de Euler son más fáciles de " +#~ "entender cuando se comparan con la representación eje-ángulo (la cual es " +#~ "normalmente, aunque no necesariamente, implementada a través de " +#~ "cuaterniones). Si bien esto puede ser cierto si está creando una " +#~ "biblioteca de álgebra lineal desde cero, o si está rellenando los " +#~ "elementos de la matriz de transformación por su cuenta, este no es el " +#~ "caso cuando escribe juegos con motores de juego, como Godot. La " +#~ "popularidad de los ángulos de Euler perduró a pesar de que, de hecho, no " +#~ "pueden representar una transición suave entre dos rotaciones diferentes " +#~ "por una variación suave de los tres ángulos. La razón de esto radica en " +#~ "el hecho de que los ángulos de Euler describen una gráfica en 3-toroides, " +#~ "que no es un `espacio recubridor `_ de las rotaciones tridimensionales de SO(3), (si " +#~ "esto suena demasiado abstracto, ver la subsección sobre 3-toroides y " +#~ "esfera abajo). Como el mapeo de los ángulos de Euler a SO(3) está mal " +#~ "definido en ciertos puntos, durante la interpolación suave entre dos " +#~ "rotaciones, podemos toparnos con tales puntos, y como resultado el rango " +#~ "puede caer a 2 o incluso 1 (lo que mecánicamente corresponde a una " +#~ "situación en la que dos o tres balancines se alinean a medida que giran), " +#~ "lo que se conoce como el problema `bloqueo del cardán `_)." +#~ msgstr "" +#~ "Imagina una hormiga caminando sobre la superficie de la rosquilla que se " +#~ "muestra a continuación (imagen tomada de `aquí `_)." + +#~ msgid "" +#~ "If it keeps walking along either the red or the blue lines, it will " +#~ "eventually come back to where it started. At any time, we can use two " +#~ "angles to describe where the ant is: one angle (:math:`\\theta` which " +#~ "goes between :math:`0` and :math:`2\\pi`) describing it's position along " +#~ "the red line, and another one (:math:`\\phi`, again between :math:`0` " +#~ "and :math:`2\\pi`) for the blue line. And note that we have periodicity: :" +#~ "math:`(\\theta,\\phi)` and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` " +#~ "describe exactly the same point on the donut for an integer :math:`N`. We " +#~ "have two angles, of course, because we're talking about a two-dimensional " +#~ "surface. Now we're ready to talk about :math:`n`-dimensional surfaces." +#~ msgstr "" +#~ "Si continúa caminando a lo largo de las líneas rojas o azules, " +#~ "eventualmente regresará a donde comenzó. En cualquier momento, podemos " +#~ "usar dos ángulos para describir dónde está la hormiga: uno (:math:`" +#~ "\\theta` que va entre :math:`0` y :math:`2\\pi`) describiendo su posición " +#~ "a lo largo de la línea roja, y otro (:math:`\\phi`, otra vez entre :math:" +#~ "`0` y :math:`2\\pi`) para la línea azul. Y ten en cuenta que tenemos " +#~ "periodicidad: :math:`(\\theta,\\phi)` y :math:`(\\theta + 2\\pi N,\\phi + " +#~ "2\\pi N)` describen exactamente el mismo punto en la rosquilla para un " +#~ "entero `mateh:`N`. Tenemos dos ángulos, por supuesto, porque estamos " +#~ "hablando de una superficie bidimensional. Ahora estamos listos para " +#~ "hablar de :math:`n`-superficies dimensionales." + +#~ msgid "" +#~ "If you have a set of :math:`n` \"coordinates\" (or angles) which are " +#~ "periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " +#~ "case for the three Euler angles), then people say those coordinates " +#~ "describe a point on the surface of an :math:`n`-torus. (In the case that " +#~ "the period of a \"coordinate\" is different than :math:`2\\pi`, that " +#~ "coordinate can be scaled to make it so, such that it corresponds to an :" +#~ "math:`n`-torus)." +#~ msgstr "" +#~ "Si tenemos un conjunto de :math:`n` \"coordenadas\" (o ángulos) que son " +#~ "periódicas, igual que lo fueron :math:`\\theta` y :math:`\\phi` (que es " +#~ "el caso de los tres ángulos de Euler), entonces la gente dice que esas " +#~ "coordenadas describen un punto en la superficie de un toroide-:math:`n`. " +#~ "(En el caso de que el período de una \"coordenada\" sea diferente a :math:" +#~ "`2\\pi`, esa coordenada puede ser escalada para hacerla así, de tal forma " +#~ "que corresponda a un toroide-:math:`n`)." + +#~ msgid "" +#~ "Now, back to our original issue. The axis of the axis-angle " +#~ "parametrization (which is *the* natural way of parametrizing rotations, " +#~ "and is a one-to-one covering map of SO(3); in fact, this is true for all " +#~ "Lie groups, not just rotations in 3D) spans a sphere (every point in a " +#~ "ball of radius :math:`\\pi` corresponds to a rotation in SO(3) where the " +#~ "rotation amount is mapped to radius and rotation axis points is the " +#~ "direction from the origin; with the additional caveat that if you flip " +#~ "the sign of the axis and angle simultaneously, it maps to the same " +#~ "rotation), which is described using spherical coordinates, whereas Euler " +#~ "angles span the surface of a 3-torus (such that every point on the 3-" +#~ "torus corresponds to a rotation), which is described by the three Euler " +#~ "angles. The problem here is, a sphere is topologically different from a " +#~ "torus. In simple terms, this means that it's impossible to deform a " +#~ "sphere to a torus \"smoothly\": at some point, you have to punch a hole " +#~ "in it to make a donut from a ball (and you can never \"punch a hole\" or " +#~ "change the topology when you stick with a parametrization: if you use " +#~ "Euler angles, you're forever stuck walking the surface of a 3-donut, and " +#~ "if you use axis-angle, you're forever stuck flying inside the sphere)." +#~ msgstr "" +#~ "Ahora, volvamos a nuestro número original. El eje de la parametrización " +#~ "eje-ángulo (que es *la* forma natural de parametrizar las rotaciones, y " +#~ "es un mapa de cobertura uno a uno de SO(3); de hecho, esto es válido para " +#~ "todos los grupos de Lie, no sólo para las rotaciones en 3D) abarca una " +#~ "esfera (cada punto en una bola de radio :math:`\\pi` corresponde a una " +#~ "rotación en SO(3) en la que la cantidad de rotación se mapea al radio y " +#~ "los puntos del eje de rotación son la dirección desde el origen; con la " +#~ "advertencia adicional de que si volteas el signo del eje y el ángulo " +#~ "simultáneamente, se mapea a la misma rotación), que se describe usando " +#~ "coordenadas esféricas, mientras que los ángulos de Euler abarcan la " +#~ "superficie de 3-toroides (de tal forma que cada punto en los 3-toroides " +#~ "corresponde a una rotación), que se describe con los tres ángulos de " +#~ "Euler. El problema aquí es que una esfera es topológicamente diferente a " +#~ "un toroide. En términos simples, esto significa que es imposible deformar " +#~ "una esfera a un toroide \"suavemente\": en algún momento, tienes que " +#~ "hacer un agujero en ella para hacer una rosquilla de una bola (y nunca " +#~ "puedes \"perforar un agujero\" o cambiar la topología cuando te quedas " +#~ "con una parametrización: si usas los ángulos de Euler, estás siempre " +#~ "atascado caminando por la superficie de 3-rosquillas, y si usas un eje-" +#~ "ángulo, estás siempre atascado volando dentro de la esfera)." + +#~ msgid "" +#~ "Why is this a problem at all? Because it means that a smooth walk " +#~ "(flight?) inside the sphere doesn't always correspond to a smooth walk on " +#~ "the surface of the 3-torus, vice versa: a 3-torus and sphere are globally " +#~ "different, which is a fact you're bound to discover if you walk the " +#~ "parameter space by a smoothly rotating a body using these " +#~ "parametrizations. Axis-angle parametrization has singularities at the " +#~ "poles (where the azimuthal angle is ill-defined) but that's fine because " +#~ "that's exactly how SO(3) is, after all, axis-angle is how Lie groups are " +#~ "parametrized. Euler angle parametrization also has singularities " +#~ "corresponding to points where two gimbals are aligned, but those " +#~ "singularities are different from SO(3)'s poles." +#~ msgstr "" +#~ "¿Por qué es esto un problema? Porque significa que una caminata suave " +#~ "(¿vuelo?) dentro de la esfera no siempre corresponde a una caminata suave " +#~ "en la superficie de 3-toroides, viceversa: 3-toroides y una esfera son " +#~ "completamente diferentes, lo cual es un hecho que estás obligado a " +#~ "descubrir si caminas por el espacio de parámetros girando suavemente un " +#~ "cuerpo usando estas parametrizaciones. La parametrización eje-ángulo " +#~ "tiene singularidades en los polos (donde el ángulo acimutal está mal " +#~ "definido) pero eso está bien porque así es exactamente como está SO(3), " +#~ "después de todo, el eje-ángulo es como se parametrizan los grupos de Lie. " +#~ "La parametrización del ángulo de Euler también tiene singularidades " +#~ "correspondientes a puntos en los que se alinean dos cardanes, pero esas " +#~ "singularidades son diferentes de los polos de SO(3)." + +#~ msgid "" +#~ "Suppose that you're at a nice spot, a rotation that can be parametrized " +#~ "by both axis-angle and Euler angles uniquely. Sometimes, it can just " +#~ "happen that if you take a wrong step, you'll fall into a \"hole" +#~ "\" (meaning a singularity at which infinitely many parameters correspond " +#~ "to the same rotation, like at the poles, all choices for the azimuthal " +#~ "angle give the same rotation, or the similar situation with gimbal lock) " +#~ "in one parametrization, while you can continue a smooth journey in the " +#~ "other parametrization. When you fall a \"hole\" using Euler angles, it's " +#~ "called gimbal lock, and since there may not be a corresponding \"hole\" " +#~ "when you take the similar step in the sphere, this tells us that Euler " +#~ "angles is a defective parametrization of SO(3)." +#~ msgstr "" +#~ "Supón que estás en un buen punto, una rotación que puede ser " +#~ "parametrizada por ambos ángulos de eje y Euler únicamente. A veces, puede " +#~ "ocurrir que si das un paso equivocado, caigas en un \"agujero\" (es " +#~ "decir, una singularidad en la que infinitamente muchos parámetros " +#~ "corresponden a la misma rotación, como en los polos, todas las opciones " +#~ "para el ángulo acimutal dan la misma rotación, o la situación similar con " +#~ "el bloqueo del cardán) en una parametrización, mientras que puedes " +#~ "continuar un viaje suave en la otra parametrización. Cuando se cae un " +#~ "\"agujero\" usando los ángulos de Euler, se llama bloqueo de cardán, y " +#~ "como puede no haber un \"agujero\" correspondiente cuando se da un paso " +#~ "similar en la esfera, esto nos dice que los ángulos de Euler son una " +#~ "parametrización defectuosa de SO(3)." + +#~ msgid "" +#~ "The root of the problem isn't just the fact that Euler angle " +#~ "parametrization has singularties, just as axis-angle does which is fine " +#~ "on its own, but that those singularities don't match with SO(3)'s " +#~ "singularities." +#~ msgstr "" +#~ "La raíz del problema no es sólo el hecho de que la parametrización del " +#~ "ángulo de Euler tiene singularidades, como lo hace el eje-ángulo, que " +#~ "está bien por sí solo, sino que esas singularidades no coinciden con las " +#~ "singularidades de SO(3)." + +#~ msgid "This is the mathematical description of the gimbal-lock problem." +#~ msgstr "" +#~ "Esta es la descripción matemática del problema del bloqueo del cardán." + +#~ msgid "" +#~ "Here's an example of gimbal lock in Euler angle parametrization. Suppose " +#~ "that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " +#~ "inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " +#~ "side and rearranging terms, we can show that" +#~ msgstr "" +#~ "He aquí un ejemplo de bloqueo del cardán en la parametrización del ángulo " +#~ "de Euler. Supongamos que una de las rotaciones es :math:`\\pi/2`, digamos " +#~ "la del medio. Insertando un operador de identidad :math:`X(-\\pi/2) " +#~ "X(\\pi/2)` en el lado derecho y reorganizando los términos, podemos " +#~ "probar que" + +#~ msgid "" +#~ "(see the section about active transformation below about how a rotation " +#~ "matrix itself transforms, which also explains why and how a Z rotation " +#~ "turns into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-" +#~ "\\pi/2` X rotations) which means we lost a degree of freedom: :math:`" +#~ "\\varphi_y-\\varphi_z` effectively became a single parameter determining " +#~ "the Y rotation and we completely lost the first Z rotation. You can " +#~ "follow similar steps to show that when *any* of the YXZ Euler angles " +#~ "become :math:`\\pm \\pi/2`, you get a gimbal lock." +#~ msgstr "" +#~ "(ver la sección sobre transformación activa más adelante sobre cómo se " +#~ "transforma una matriz de rotación, que también explica por qué y cómo una " +#~ "rotación Z se convierte en una rotación Y cuando está rodeada de :math:`" +#~ "\\pi/2` y :math:`-\\pi/2` X rotaciones) lo que significa que perdimos un " +#~ "grado de libertad: :math:`\\varphi_y-\\varphi_z` efectivamente se " +#~ "convirtió en un único parámetro determinante de la rotación Y y perdimos " +#~ "completamente la primera rotación Z. Puedes seguir pasos similares para " +#~ "mostrar que cuando *cualquiera* de los ángulos YXZ Euler se convierten " +#~ "en :math:`\\pm \\pi/2`, se obtiene un bloqueo de cardán." + +#~ msgid "" +#~ "This happens for :math:`\\pm \\pi/2` simply because in the YXZ " +#~ "convention, neighboring axes are related to each other by a :math:`\\pm " +#~ "\\pi/2` rotation around the axis given by the other neighbor. For XZX " +#~ "convention, the gimbal lock would happen at :math:`\\varphi_z = \\pm " +#~ "\\pi` for example." +#~ msgstr "" +#~ "Esto sucede para :math:`\\pm \\pi/2` simplemente porque en la convención " +#~ "YXZ, los ejes vecinos están relacionados entre sí por una rotación de :" +#~ "math:`\\pm \\pi/2` alrededor del eje dado por el otro vecino. Para la " +#~ "convención XZX, el bloqueo del cardán ocurriría por ejemplo en :math:`" +#~ "\\varphi_z = \\pm \\pi`." + +#~ msgid "Summary: representation versus parametrization" +#~ msgstr "Resumen: representación vs parametrización" + +#~ msgid "We can sum it up in a table:" +#~ msgstr "Podemos resumirlo en una tabla:" + +#~ msgid "Parametrization/Representation" +#~ msgstr "Parametrización/Representación" + +#~ msgid "Axis-angle" +#~ msgstr "Ejes-ángulo" + +#~ msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" +#~ msgstr ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" + +#~ msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" +#~ msgstr ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" + +#~ msgid "Euler-angles" +#~ msgstr "Ángulos de Euler" + +#~ msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" +#~ msgstr ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" + +#~ msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" +#~ msgstr ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" + +#~ msgid "" +#~ "where :math:`\\boldsymbol J` denotes the matrix representation of the :" +#~ "math:`\\boldsymbol J` operators (too lazy to introduce a new symbol for " +#~ "that). YXZ Euler angles is chosen for concreteness (as it is the default " +#~ "convention in Godot), and can be replaced by any three axes (as long as " +#~ "two neighboring axes aren't the same)." +#~ msgstr "" +#~ "donde :math:`\\boldsymbol J` denota la representación matricial de los " +#~ "operadores :math:`\\boldsymbol J` (demasiado perezosos para introducir un " +#~ "nuevo símbolo para eso). Los ángulos de Euler XYZ se eligen para " +#~ "concretar (ya que es la convención por defecto en Godot), y pueden ser " +#~ "reemplazados por tres ejes cualquiera (siempre y cuando dos ejes vecinos " +#~ "no sean iguales)." + +#~ msgid "" +#~ "In all cases listed in the above table, Rodrigues' formula (or it's " +#~ "analogue for quaternions) given above can be used for practical purposes." +#~ msgstr "" +#~ "En todos los casos enumerados en la tabla anterior, la fórmula de " +#~ "Rodrigues (o es análoga para los cuaterniones) indicada anteriormente " +#~ "puede utilizarse con fines prácticos." + +#~ msgid "" +#~ "In the context of 3D rotations, one representation isn't superior or " +#~ "inferior to another. Whatever representation you're using, you are " +#~ "representing exactly the same thing. A difference appears only when you " +#~ "implement it on a computer: different representations have trade offs " +#~ "when it comes to precision errors, CPU cycles and memory usage (for " +#~ "example, accessing to rotation axis-angle with quaternions is trivial but " +#~ "requires some algebra in matrix representation whereas the converse is " +#~ "true when accessing the basis vectors, SLERP, composition of rotations " +#~ "and orthonormalization is faster with quaternions but a conversion to " +#~ "matrix representation, which isn't free, is always required because " +#~ "that's the representation OpenGL uses and rotating a 3D vector is faster " +#~ "in matrix representation since they are written in the same basis), and " +#~ "they may have different characteristics when doing finite precision " +#~ "arithmetic with floating point numbers. In principle, you can do " +#~ "everything you do with quaternions using matrices, vice versa. The " +#~ "performance could be bad in one representation, but the point is, there " +#~ "is nothing in their mathematics that prevent you from doing that." +#~ msgstr "" +#~ "En el contexto de las rotaciones 3D, una representación no es superior o " +#~ "inferior a otra. Cualquiera que sea la representación que estés usando, " +#~ "estás representando exactamente lo mismo. Las diferencias sólo aparecen " +#~ "cuando se implementan en una computadora: diferentes representaciones " +#~ "tienen compensaciones cuando se trata de errores de precisión, ciclos de " +#~ "CPU y uso de memoria (por ejemplo, acceder al ángulo del eje de rotación " +#~ "con cuaterniones es trivial pero requiere algo de álgebra en la " +#~ "representación de la matriz mientras que lo contrario es aplicable cuando " +#~ "se accede a los vectores base, SLERP, la composición de rotaciones y " +#~ "ortonormalización es más rápida con cuaterniones, pero siempre se " +#~ "requiere una conversión a representación matricial, que no es libre, " +#~ "porque esa es la representación que utiliza OpenGL y girar un vector 3D " +#~ "es más rápido en la representación matricial ya que están escritos en la " +#~ "misma base), y pueden tener características diferentes cuando se hace " +#~ "aritmética de precisión finita con números de coma flotante. En " +#~ "principio, se puede hacer todo lo que se hace con los cuaterniones " +#~ "utilizando matrices, y viceversa. El desempeño podría ser malo en una " +#~ "representación, pero el punto es que no hay nada en sus matemáticas que " +#~ "le impida hacer eso." + +#~ msgid "" +#~ "Parametrizations, on the other hand, are vastly different. Axis-angle is " +#~ "the \"one true\" parametrization of rotations. Euler angles, despite " +#~ "being a defective parametrization of rotations, could be more intuitive " +#~ "for simple (involving only 1 or 2 angles) and *static* situations like " +#~ "orienting a body/vehicle in the editor, but should be avoided for " +#~ "rotational *dynamics* which would eventually lead to a gimbal lock." +#~ msgstr "" +#~ "Las parametrizaciones, por otro lado, son muy diferentes. El ángulo del " +#~ "eje es la \"única\" parametrización verdadera de las rotaciones. Los " +#~ "ángulos de Euler, a pesar de ser una parametrización defectuosa de las " +#~ "rotaciones, podrían ser más intuitivos para situaciones simples " +#~ "(involucrando sólo 1 o 2 ángulos) y *estáticas* como orientar una " +#~ "carrocería/vehículo en el editor, pero deberían ser evitados por la " +#~ "*dinámica* rotacional que eventualmente llevaría a un bloqueo del cardán." + +#~ msgid "Interpolating rotations" +#~ msgstr "Interpolación de rotaciones" + +#~ msgid "" +#~ "In games, it's common problem to interpolate between two different " +#~ "orientation in a \"nice way\" which doesn't depend on arbitrary things " +#~ "like how the reference frame, and which doesn't result in a \"jerky\" " +#~ "motion (that is, a torque-free motion) such that the angular speed " +#~ "remains constant during the interpolation. These are the properties that " +#~ "we seek when we say \"nice\"." +#~ msgstr "" +#~ "En los juegos, es un problema común interpolar entre dos orientaciones " +#~ "diferentes de una manera \"agradable\" que no depende de cosas " +#~ "arbitrarias como el cuadro de referencia, y que no resulta en un " +#~ "movimiento \"brusco\" (es decir, un movimiento sin torsión) tal que la " +#~ "velocidad angular permanece constante durante la interpolación. Estas son " +#~ "las propiedades que buscamos cuando decimos \"agradable\"." + +#~ msgid "" +#~ "Formally, we'd like to interpolate between an initial rotation :math:`R_1 " +#~ "= e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a " +#~ "final one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol " +#~ "J }` a function of time, and what we're seeking is something that " +#~ "transforms one into another smoothly, :math:`R(\\lambda)`, where :math:`" +#~ "\\lambda` is the normalized time which is 0 at the beginning and 1 at the " +#~ "end. Clearly, we must have :math:`R(\\lambda=0)=R_1` and :math:" +#~ "`R(\\lambda=1) = R_2`. Since we also know that rotations form a group, we " +#~ "can relate :math:`R(\\lambda)` to :math:`R_1` and :math:`R_2` using " +#~ "another rotation, such that we can for example write" +#~ msgstr "" +#~ "Nos gustaría interpolar formalmente entre una rotación inicial :math:`R_1 " +#~ "= e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` y una " +#~ "final :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` " +#~ "una función de tiempo, y lo que estamos buscando es algo que se " +#~ "transforme el uno en el otro suavemente, :math:`R(\\lambda)`, donde :math:" +#~ "`\\lambda` es el tiempo normalizado, siendo 0 al principio y 1 al final. " +#~ "Claramente, debemos tener :math:`R(\\lambda=0)=R_1` y :math:" +#~ "`R(\\lambda=1) = R_2`. Como ya sabemos que las rotaciones forman un " +#~ "grupo, podemos relacionar :math:`R(\\lambda)` con :math:`R_1` and :math:" +#~ "`R_2` usando otra rotación, de manera que, por ejemplo, podamos escribir" + +#~ msgid "" +#~ "This form makes sense because for :math:`\\lambda=0`, the interpolation " +#~ "hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " +#~ "But why not pick a different form for the exponent as a function of :math:" +#~ "`\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " +#~ "because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " +#~ "\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" +#~ "math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " +#~ "constant, which can only happen if the time derivative of the exponent is " +#~ "linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " +#~ "\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " +#~ "rotation around a fixed axis (fixed because otherwise if you tilt the " +#~ "rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " +#~ "force `_) with constant " +#~ "angular speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }" +#~ "` where the exponent is linear in time." +#~ msgstr "" +#~ "Esta forma tiene sentido porque para :math:`\\lambda=0`, la interpolación " +#~ "no ha comenzado y :math:`R(\\lambda)` se convierte automáticamente en :" +#~ "math:`R_1`. Pero, ¿por qué no elegir una forma diferente para el " +#~ "exponente en función de :math:`\\lambda` que se evalúa a 0 cuando :math:`" +#~ "\\lambda=0`? Eso es simplemente porque no queremos tener un movimiento " +#~ "brusco, lo que significa :math:`\\boldsymbol \\omega \\cdot \\boldsymbol " +#~ "J = R^T(\\lambda) \\dot R(\\lambda)`, dónde :math:`\\boldsymbol \\omega` " +#~ "es el vector de velocidad angular, tiene que ser una constante, lo que " +#~ "sólo puede ocurrir si la derivada temporal del exponente es lineal en el " +#~ "tiempo (en cuyo caso obtenemos :math:`\\boldsymbol \\omega = \\varphi " +#~ "\\boldsymbol n`). O su equivalente, simplemente se puede observar que una " +#~ "rotación alrededor de un eje fijo (fijo porque de lo contrario, si " +#~ "inclinas el eje de rotación en el tiempo, obtendrás de nuevo un " +#~ "\"movimiento brusco\" debido a la `Fuerza de Euler \n" "Language-Team: Spanish (Mexico) ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3263,109 +3265,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3373,55 +3375,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3429,57 +3431,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3489,17 +3491,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3507,7 +3509,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3515,55 +3517,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3571,24 +3573,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6332,7 +6334,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6355,7 +6357,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6366,8 +6368,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6389,7 +6391,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6453,27 +6455,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6481,17 +6483,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6501,54 +6503,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6557,7 +6559,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6566,18 +6568,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6585,7 +6587,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6593,14 +6595,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6610,60 +6612,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6673,11 +6675,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6685,7 +6687,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6693,15 +6695,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6710,38 +6712,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6750,20 +6752,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6771,15 +6773,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6928,7 +6930,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -6968,7 +6970,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7012,7 +7014,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7036,7 +7038,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7072,7 +7074,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7092,14 +7094,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7109,11 +7111,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7121,7 +7123,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7135,7 +7137,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7150,7 +7152,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7274,7 +7276,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7316,8 +7318,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7351,7 +7353,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7377,19 +7379,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7414,7 +7416,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7437,7 +7439,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7455,7 +7457,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7472,8 +7474,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7508,7 +7510,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7679,7 +7681,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7689,25 +7691,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7728,183 +7730,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7912,17 +7914,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7930,139 +7932,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8072,7 +8074,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8082,69 +8084,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8152,125 +8154,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8278,7 +8280,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8302,7 +8304,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8339,79 +8341,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8419,36 +8421,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11696,10 +11698,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12750,7 +12752,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13395,6 +13397,256 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14296,136 +14548,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14433,113 +14699,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14548,15 +14814,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14564,34 +14830,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14599,15 +14865,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14615,51 +14881,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14667,102 +14933,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14770,44 +15036,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16716,7 +16982,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16741,8 +17007,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16777,7 +17043,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16822,16 +17088,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16927,7 +17193,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17056,7 +17322,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17196,7 +17462,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17211,7 +17477,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17311,44 +17577,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17357,17 +17623,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17379,7 +17645,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17391,25 +17657,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17417,61 +17683,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17482,29 +17748,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17621,9 +17887,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17632,8 +17898,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17872,8 +18138,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18132,7 +18398,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18180,7 +18446,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18318,7 +18584,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18351,10 +18617,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18787,16 +19049,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18839,6 +19101,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19162,8 +19425,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19177,14 +19440,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19216,67 +19479,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19285,334 +19548,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19620,11 +19883,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19633,30 +19896,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19664,11 +19927,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19678,11 +19941,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19691,66 +19954,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19758,38 +20021,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19800,13 +20063,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19849,8 +20112,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19861,7 +20124,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19889,56 +20152,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19946,26 +20209,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -19973,23 +20236,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -19998,129 +20261,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20128,111 +20390,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20262,61 +20524,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20324,7 +20587,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20332,42 +20595,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20375,31 +20638,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20414,186 +20677,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20607,38 +20870,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20647,44 +20910,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20692,27 +20955,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20720,7 +20983,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20728,13 +20991,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20743,113 +21006,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20857,110 +21120,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -20968,12 +21231,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -20986,213 +21249,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21200,38 +21463,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21241,149 +21504,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21391,143 +21654,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21535,78 +21799,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21647,10 +21911,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21702,11 +21966,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21742,7 +22006,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21753,8 +22017,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21769,23 +22033,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21796,7 +22061,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22010,9 +22275,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22020,46 +22285,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22067,92 +22333,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22174,28 +22439,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22204,7 +22468,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22215,7 +22479,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22225,50 +22489,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22276,137 +22540,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22414,31 +22687,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22452,45 +22725,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22498,68 +22776,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22567,14 +22845,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22587,8 +22865,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22632,7 +22910,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30111,14 +30389,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30138,40 +30416,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30179,37 +30461,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30217,7 +30499,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30227,79 +30509,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30307,7 +30587,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30319,39 +30599,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30360,11 +30640,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30372,51 +30652,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30424,55 +30704,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30481,11 +30761,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30765,10 +31045,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32627,1532 +32903,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40144,7 +38894,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40532,226 +39282,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47197,9 +46066,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47253,7 +46122,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51849,6 +50718,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/fa.po b/weblate/fa.po index 1eb2e33f74..171a0e9735 100644 --- a/weblate/fa.po +++ b/weblate/fa.po @@ -9,7 +9,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-09 01:41+0000\n" "Last-Translator: Amir Hossein Mafi \n" "Language-Team: Persian ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3303,109 +3305,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3413,55 +3415,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3469,57 +3471,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3529,17 +3531,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3547,7 +3549,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3555,55 +3557,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3611,24 +3613,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6374,7 +6376,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6397,7 +6399,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6408,8 +6410,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6431,7 +6433,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6495,27 +6497,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6523,17 +6525,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6543,54 +6545,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6599,7 +6601,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6608,18 +6610,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6627,7 +6629,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6635,14 +6637,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6652,60 +6654,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6715,11 +6717,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6727,7 +6729,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6735,15 +6737,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6752,38 +6754,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6792,20 +6794,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6813,15 +6815,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6970,7 +6972,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7010,7 +7012,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7054,7 +7056,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7078,7 +7080,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7114,7 +7116,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7134,14 +7136,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7151,11 +7153,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7163,7 +7165,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7177,7 +7179,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7192,7 +7194,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7316,7 +7318,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7358,8 +7360,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7393,7 +7395,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7419,19 +7421,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7456,7 +7458,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7479,7 +7481,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7497,7 +7499,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7514,8 +7516,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7550,7 +7552,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7721,7 +7723,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7731,25 +7733,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7770,183 +7772,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "مجوز" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7954,17 +7956,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7972,139 +7974,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8114,7 +8116,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8124,69 +8126,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8194,125 +8196,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8320,7 +8322,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8344,7 +8346,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8381,79 +8383,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8461,36 +8463,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11741,10 +11743,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12796,7 +12798,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13441,6 +13443,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +#, fuzzy +msgid "Export of Blender materials" +msgstr "منوی خروجی گرفتن" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14342,136 +14595,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14479,113 +14746,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14594,15 +14861,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14610,34 +14877,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14645,15 +14912,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14661,51 +14928,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14713,102 +14980,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14816,44 +15083,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16769,7 +17036,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16794,8 +17061,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16830,7 +17097,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16875,16 +17142,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16980,7 +17247,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17109,7 +17376,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17249,7 +17516,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17264,7 +17531,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17364,44 +17631,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17410,17 +17677,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17432,7 +17699,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17444,25 +17711,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17470,61 +17737,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17535,29 +17802,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17674,9 +17941,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17685,8 +17952,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17925,8 +18192,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18185,7 +18452,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18233,7 +18500,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18371,7 +18638,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18404,10 +18671,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18840,16 +19103,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18892,6 +19155,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19215,8 +19479,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19230,14 +19494,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19269,67 +19533,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19338,334 +19602,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19673,11 +19937,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19686,30 +19950,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19717,11 +19981,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19731,11 +19995,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19744,66 +20008,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19811,38 +20075,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19853,13 +20117,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19902,8 +20166,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19914,7 +20178,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19942,56 +20206,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19999,26 +20263,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20026,23 +20290,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20051,129 +20315,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20181,111 +20444,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20315,61 +20578,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20377,7 +20641,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20385,42 +20649,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20428,31 +20692,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20467,186 +20731,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20660,38 +20924,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20700,44 +20964,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20745,27 +21009,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20773,7 +21037,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20781,13 +21045,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20796,113 +21060,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20910,110 +21174,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21021,12 +21285,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21039,213 +21303,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21253,38 +21517,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21294,149 +21558,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21444,143 +21708,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21588,78 +21853,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21700,10 +21965,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21755,11 +22020,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21795,7 +22060,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21806,8 +22071,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21822,23 +22087,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21849,7 +22115,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22063,9 +22329,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22073,46 +22339,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22120,92 +22387,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22227,28 +22493,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22257,7 +22522,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22268,7 +22533,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22278,50 +22543,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22329,137 +22594,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22467,31 +22741,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22505,45 +22779,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22551,68 +22830,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22620,14 +22899,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22640,8 +22919,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22685,7 +22964,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30164,14 +30443,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30191,40 +30470,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30232,37 +30515,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30270,7 +30553,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30280,79 +30563,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30360,7 +30641,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30372,39 +30653,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30413,11 +30694,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30425,51 +30706,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30477,55 +30758,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30534,11 +30815,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30818,10 +31099,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32680,1532 +32957,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40197,7 +38948,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40585,226 +39336,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47250,9 +46120,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47306,7 +46176,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51903,6 +50773,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/fi.po b/weblate/fi.po index 37134b89ca..39872b3891 100644 --- a/weblate/fi.po +++ b/weblate/fi.po @@ -11,7 +11,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-18 06:41+0000\n" "Last-Translator: Tapani Niemi \n" "Language-Team: Finnish ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3398,109 +3401,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3508,55 +3511,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3564,57 +3567,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3624,17 +3627,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3642,7 +3645,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3650,55 +3653,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "Partikkelit" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3706,24 +3709,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6467,7 +6470,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6490,7 +6493,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6501,8 +6504,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6524,7 +6527,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6588,27 +6591,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6616,17 +6619,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6636,54 +6639,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6692,7 +6695,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6701,18 +6704,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6720,7 +6723,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6728,14 +6731,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6745,60 +6748,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6808,11 +6811,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6820,7 +6823,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6828,15 +6831,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6845,38 +6848,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6885,20 +6888,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6906,15 +6909,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7063,7 +7066,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7103,7 +7106,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7147,7 +7150,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7171,7 +7174,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7207,7 +7210,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7227,14 +7230,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7244,11 +7247,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7256,7 +7259,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7270,7 +7273,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7285,7 +7288,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7409,7 +7412,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7451,8 +7454,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7486,7 +7489,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7512,19 +7515,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7549,7 +7552,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7572,7 +7575,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7590,7 +7593,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7607,8 +7610,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7643,7 +7646,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7814,7 +7817,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7824,25 +7827,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7863,183 +7866,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Lisenssi" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8047,17 +8050,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8065,139 +8068,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8207,7 +8210,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8217,69 +8220,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8287,125 +8290,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8413,7 +8416,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8437,7 +8440,7 @@ msgstr "Polku" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8474,79 +8477,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8554,36 +8557,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11831,10 +11834,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12885,7 +12888,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13530,6 +13533,258 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Godotissa ei ole mitään käyttörajoituksia" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "Tyyppi" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14431,136 +14686,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14568,113 +14837,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14683,15 +14952,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14699,34 +14968,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14734,15 +15003,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "FPS" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14750,51 +15019,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14802,102 +15071,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14905,44 +15174,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16851,7 +17120,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16876,8 +17145,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16912,7 +17181,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16957,16 +17226,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17062,7 +17331,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17191,7 +17460,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17331,7 +17600,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17346,7 +17615,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17446,44 +17715,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17492,17 +17761,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17514,7 +17783,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17526,25 +17795,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17552,61 +17821,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17617,29 +17886,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Työkalut" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17756,9 +18025,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17767,8 +18036,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -18007,8 +18276,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18267,7 +18536,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18315,7 +18584,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18453,7 +18722,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18486,10 +18755,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18922,16 +19187,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18974,6 +19239,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19297,8 +19563,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19312,14 +19578,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19351,67 +19617,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19420,334 +19686,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19755,11 +20021,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19768,30 +20034,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19799,11 +20065,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19813,11 +20079,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Syvyys" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19826,66 +20092,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19893,38 +20159,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19935,13 +20201,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19984,8 +20250,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19996,7 +20262,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -20024,56 +20290,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20081,26 +20347,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20108,23 +20374,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20133,129 +20399,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20263,111 +20528,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20397,61 +20662,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20459,7 +20725,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20467,42 +20733,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20510,31 +20776,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20549,186 +20815,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20742,38 +21008,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20782,44 +21048,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20827,27 +21093,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20855,7 +21121,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20863,13 +21129,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20878,113 +21144,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20992,110 +21258,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21103,12 +21369,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21121,213 +21387,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21335,38 +21601,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21376,149 +21642,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21526,143 +21792,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21670,78 +21937,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21782,10 +22049,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21837,11 +22104,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21877,7 +22144,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21888,8 +22155,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21904,23 +22171,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21931,7 +22199,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22145,9 +22413,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22155,46 +22423,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22202,92 +22471,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22309,28 +22577,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22339,7 +22606,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22350,7 +22617,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22360,50 +22627,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22411,137 +22678,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22549,31 +22825,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22587,45 +22863,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22633,68 +22914,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22702,14 +22983,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22722,8 +23003,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22767,7 +23048,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30246,14 +30527,14 @@ msgid "Audio" msgstr "Äänet" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30273,40 +30554,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30314,37 +30599,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30352,7 +30637,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30362,79 +30647,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30442,7 +30725,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30454,39 +30737,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30495,11 +30778,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30507,51 +30790,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30559,55 +30842,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30616,11 +30899,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30900,10 +31183,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32762,1532 +33041,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40279,7 +39032,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40667,226 +39420,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47332,9 +46204,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47388,7 +46260,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51984,6 +50856,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/fil.po b/weblate/fil.po index 4ee3dc6192..9ac34da2f5 100644 --- a/weblate/fil.po +++ b/weblate/fil.po @@ -9,7 +9,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-05-15 01:36+0000\n" "Last-Translator: Daris C. Mondigo \n" "Language-Team: Filipino ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3245,109 +3247,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3355,55 +3357,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3411,57 +3413,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3471,17 +3473,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3489,7 +3491,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3497,55 +3499,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3553,24 +3555,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6314,7 +6316,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6337,7 +6339,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6348,8 +6350,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6371,7 +6373,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6435,27 +6437,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6463,17 +6465,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6483,54 +6485,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6539,7 +6541,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6548,18 +6550,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6567,7 +6569,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6575,14 +6577,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6592,60 +6594,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6655,11 +6657,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6667,7 +6669,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6675,15 +6677,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6692,38 +6694,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6732,20 +6734,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6753,15 +6755,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6910,7 +6912,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -6950,7 +6952,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -6994,7 +6996,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7018,7 +7020,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7054,7 +7056,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7074,14 +7076,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7091,11 +7093,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7103,7 +7105,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7117,7 +7119,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7132,7 +7134,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7256,7 +7258,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7298,8 +7300,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7333,7 +7335,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7359,19 +7361,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7396,7 +7398,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7419,7 +7421,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7437,7 +7439,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7454,8 +7456,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7490,7 +7492,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7661,7 +7663,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7671,25 +7673,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7710,183 +7712,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7894,17 +7896,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7912,139 +7914,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8054,7 +8056,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8064,69 +8066,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8134,125 +8136,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8260,7 +8262,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8284,7 +8286,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8321,79 +8323,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8401,36 +8403,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11678,10 +11680,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12732,7 +12734,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13377,6 +13379,256 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14278,136 +14530,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14415,113 +14681,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14530,15 +14796,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14546,34 +14812,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14581,15 +14847,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14597,51 +14863,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14649,102 +14915,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14752,44 +15018,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16698,7 +16964,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16723,8 +16989,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16759,7 +17025,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16804,16 +17070,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16909,7 +17175,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17038,7 +17304,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17178,7 +17444,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17193,7 +17459,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17293,44 +17559,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17339,17 +17605,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17361,7 +17627,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17373,25 +17639,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17399,61 +17665,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17464,29 +17730,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17603,9 +17869,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17614,8 +17880,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17854,8 +18120,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18114,7 +18380,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18162,7 +18428,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18300,7 +18566,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18333,10 +18599,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18769,16 +19031,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18821,6 +19083,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19144,8 +19407,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19159,14 +19422,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19198,67 +19461,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19267,334 +19530,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19602,11 +19865,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19615,30 +19878,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19646,11 +19909,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19660,11 +19923,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19673,66 +19936,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19740,38 +20003,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19782,13 +20045,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19831,8 +20094,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19843,7 +20106,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19871,56 +20134,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19928,26 +20191,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -19955,23 +20218,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -19980,129 +20243,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20110,111 +20372,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20244,61 +20506,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20306,7 +20569,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20314,42 +20577,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20357,31 +20620,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20396,186 +20659,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20589,38 +20852,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20629,44 +20892,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20674,27 +20937,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20702,7 +20965,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20710,13 +20973,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20725,113 +20988,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20839,110 +21102,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -20950,12 +21213,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -20968,213 +21231,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21182,38 +21445,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21223,149 +21486,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21373,143 +21636,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21517,78 +21781,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21629,10 +21893,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21684,11 +21948,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21724,7 +21988,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21735,8 +21999,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21751,23 +22015,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21778,7 +22043,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -21992,9 +22257,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22002,46 +22267,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22049,92 +22315,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22156,28 +22421,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22186,7 +22450,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22197,7 +22461,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22207,50 +22471,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22258,137 +22522,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22396,31 +22669,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22434,45 +22707,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22480,68 +22758,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22549,14 +22827,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22569,8 +22847,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22614,7 +22892,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30093,14 +30371,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30120,40 +30398,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30161,37 +30443,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30199,7 +30481,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30209,79 +30491,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30289,7 +30569,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30301,39 +30581,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30342,11 +30622,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30354,51 +30634,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30406,55 +30686,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30463,11 +30743,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30747,10 +31027,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32609,1532 +32885,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40126,7 +38876,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40514,226 +39264,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47179,9 +46048,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47235,7 +46104,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51831,6 +50700,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/fr.po b/weblate/fr.po index 8aabe8e0ce..460104bd09 100644 --- a/weblate/fr.po +++ b/weblate/fr.po @@ -37,7 +37,7 @@ msgid "" msgstr "" "Project-Id-Version: French (Godot Engine)\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-16 12:37+0000\n" "Last-Translator: Smiley32 \n" "Language-Team: French ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " @@ -4408,23 +4415,23 @@ msgstr "" "de sorte que les informations qu'il affiche ne sont couvertes par aucun " "élément du jeu comme le joueur ou les monstres." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "Le HUD affiche les informations suivantes :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "Le score, modifié par ``ScoreTimer``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "Un message, tel que \"Game Over\" ou \"Get Ready\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "Un bouton \"Démarrer\" pour commencer le jeu." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" @@ -4435,27 +4442,27 @@ msgstr "" "nous utiliserons deux types de nœuds :ref:`Control ` : :ref:" "`Label ` et :ref:`Button `." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "Créez les éléments suivants en tant qu'enfants du nœud ``HUD`` :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "Un :ref:`Label ` nommé ``ScoreLabel``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "Un :ref:`Label ` nommé ``MessageLabel``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "Un :ref:`Button ` nommé ``StartButton``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "Un :ref:`Timer ` nommé ``MessageTimer``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -4472,7 +4479,7 @@ msgstr "" "contrôle et son ancrage. Voir :ref:" "`doc_design_interfaces_with_the_control_nodes` pour plus de détails." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" @@ -4480,7 +4487,7 @@ msgstr "" "Disposez les nœuds comme indiqué ci-dessous. Cliquez sur le bouton \"Ancrer" "\" pour définir l'ancre d'un nœud Control :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" @@ -4488,97 +4495,97 @@ msgstr "" "Vous pouvez faire glisser les nœuds pour les placer manuellement ou, pour un " "placement plus précis, utiliser les paramètres suivants :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "ScoreLabel" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "``Layout`` : \"Center Top\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "``Margin`` :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "Left : ``-25``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "Top : ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "Right : ``25``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "Bottom : ``100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "Text : ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "MessageLabel" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "``Layout`` : \"Center\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "Gauche : ``-100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "Haut : ``-150``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "Droite : ``200``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "Bas : ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "Text : ``Dodge the Creeps!``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "StartButton" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "``Layout`` : \"Center Bottom\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "Left : ``-100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "Top : ``-200``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "Right : ``100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "Bottom : ``-100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "Text : ``Start``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -4590,11 +4597,11 @@ msgstr "" "appelé \"Xolonium-Regular.ttf\". Pour utiliser cette police, procédez comme " "suit pour chacun des trois nœuds ``Control`` :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "Sous \"Polices personnalisées\", choisissez \"Nouveau DynamicFont\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " @@ -4605,18 +4612,18 @@ msgstr "" "Vous devez également définir la taille de la police de caractères. Un " "réglage à \"64\" fonctionne bien." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "Ajoutez à présent ce script à ``HUD`` :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" "Le signal ``start_game`` indique au nœud ``Main`` que le bouton a été pressé." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " @@ -4626,7 +4633,7 @@ msgstr "" "message, tel que \"Get Ready\". Sur le ``MessageTimer``, mettez ``Wait " "Time`` sur ``2`` et la propriété ``One Shot`` sur \"On\"." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." @@ -4635,12 +4642,12 @@ msgstr "" "\" pendant 2 secondes, puis reviendra à l'écran de titre et affichera le " "bouton \"Start\"." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" "Cette fonction est appelée dans ``Main`` chaque fois que le score change." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." @@ -4648,11 +4655,11 @@ msgstr "" "Connectez le signal ``timeout()`` du ``MessageTimer`` et le signal " "``appuyé()`` du ``StartButton``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "Connecter le HUD au Main" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -4665,7 +4672,7 @@ msgstr "" "L'arbre complet devrait ressembler à ceci, alors assurez-vous de ne rien " "manquer :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" @@ -4673,7 +4680,7 @@ msgstr "" "Nous devons maintenant connecter la fonctionnalité ``HUD``à notre script " "``Main``. Cela nécessite quelques ajouts à la scène ``Main`` :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." @@ -4681,7 +4688,7 @@ msgstr "" "Dans l'onglet Nœud, connectez le signal ``start_game`` du HUD à la fonction " "``new_game()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" @@ -4689,12 +4696,12 @@ msgstr "" "Dans ``new_game()``, mettez à jour l'affichage des scores et affichez le " "message \"Get Ready\" :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" "Dans ``game_over()`` nous devons appeler la fonction ``HUD`` correspondante :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" @@ -4702,7 +4709,7 @@ msgstr "" "Enfin, ajoutez ceci à ``on_ScoreTimer_timeout()`` pour que l'affichage reste " "synchronisé avec le changement de score :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." @@ -4711,11 +4718,11 @@ msgstr "" "\". Il vous sera demandé de sélectionner une scène principale, choisissez " "alors ``Main.tscn``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "Pour terminer" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " @@ -4726,12 +4733,12 @@ msgstr "" "pour améliorer l'expérience de jeu. N'hésitez pas à développer le gameplay " "avec vos propres idées." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "Arrière-plan" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -4747,7 +4754,7 @@ msgstr "" "propriété : ``Color``. Choisissez une couleur que vous aimez et faites " "glisser la taille du ``ColorRect`` pour qu'il couvre l'écran." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." @@ -4755,11 +4762,11 @@ msgstr "" "Vous pouvez aussi ajouter une image de fond, si vous en avez une, en " "utilisant un nœud ``Sprite``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "Effets sonores" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -4771,7 +4778,7 @@ msgstr "" "vous avez deux fichiers son : \"House In a Forest Loop.ogg\" pour la musique " "de fond, et \"gameover.wav\" pour quand le joueur perd." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -4783,7 +4790,7 @@ msgstr "" "``DeathSound``. Sur chacun d'eux, cliquez sur la propriété ``Stream``, " "sélectionnez \"Charger\", et choisissez le fichier audio correspondant." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." @@ -4791,17 +4798,17 @@ msgstr "" "Pour jouer de la musique, ajouter ``$Music.play()`` dans la fonction " "``new_game()`` et ``$Music.stop()`` dans la fonction ``game_over()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" "Enfin, ajoutez ``$DeathSound.play()`` dans la fonction ``game_over()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "Particules" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " @@ -4811,7 +4818,7 @@ msgstr "" "mouvement du joueur. Choisissez votre scène ``Player`` et ajoutez un nœud :" "ref:`Particles2D ` nommé ``Trail``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " @@ -4821,7 +4828,7 @@ msgstr "" "des particules. N'hésitez pas à expérimenter et à créer des effets " "différents. Pour l'effet dans cet exemple, utilisez les paramètres suivants :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" @@ -4829,7 +4836,7 @@ msgstr "" "Vous devez également créer un ``Material`` en cliquant sur ```` puis " "sur \"Nouveau ParticlesMaterial\". Les paramètres pour cela sont ci-dessous :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " @@ -4839,7 +4846,7 @@ msgstr "" "dégradé prenant l'alpha (transparence) du sprite de 0.5 (semi-transparent) à " "0.0 (totalement transparent)." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" @@ -4847,7 +4854,7 @@ msgstr "" "Cliquez sur \"Nouveau GradientTexture\", puis sous \"Gradient\", cliquez sur " "\"Nouveau Gradient\". Vous verrez une fenêtre comme celle-ci :" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -4859,7 +4866,7 @@ msgstr "" "pour choisir la couleur. Pour la première couleur, réglez la valeur " "``A``(alpha) à environ la moitié. Pour la seconde, réglez à ``0``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." @@ -4867,11 +4874,11 @@ msgstr "" "Voir :ref:`Particles2D ` pour plus de détails " "sur l'utilisation des effets de particules." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "Fichiers du project" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" @@ -4880,7 +4887,7 @@ msgstr "" "com/kidscancode/Godot3_dodge/releases" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "Exportation" @@ -9077,7 +9084,8 @@ msgstr "" "nœuds, pour écouter celui que vous avez sélectionné." #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +#, fuzzy +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" "La première section énumère les signaux personnalisés définis dans ``player." "GD`` :" @@ -9100,12 +9108,13 @@ msgid "We're connecting to the health\\_changed signal" msgstr "On se connecte au signal health\\_changed" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:234 +#, fuzzy msgid "" "Select ``health_changed`` and click on the Connect button in the bottom " "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -9123,9 +9132,10 @@ msgid "The Connect Signal window with the GUI node selected" msgstr "La fenêtre Connecter un signal avec le nœud GUI sélectionné" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 +#, fuzzy msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" "Vous pouvez éventuellement connecter des nœuds à partir du code. Mais le " "faire à partir de l'éditeur a deux avantages :" @@ -9145,6 +9155,7 @@ msgstr "" "de scène" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:253 +#, fuzzy msgid "" "At the bottom of the window you will find the path to the node you selected. " "We're interested in the second row called \"Method in Node\". This is the " @@ -9153,7 +9164,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" "En bas de la fenêtre, vous trouverez le chemin d'accès au nœud que vous avez " "sélectionné. Nous nous intéressons à la deuxième ligne appelée \"Méthode " @@ -9258,12 +9269,12 @@ msgstr "" "``_on_Player_health_changed``. Elle prends ``new\\_value`` comme seul " "argument." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 #, fuzzy msgid "This method needs to:" msgstr "Cette fonction a besoin de :" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 #, fuzzy msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" @@ -9271,14 +9282,14 @@ msgstr "" "d'assigner ``new_value`` à la propriété ``text`` du nœud ``Number``. Il ne " "faut pas oublier de convertir cette valeur en chaîne de caractères." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 #, fuzzy msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" "d'assigner ``new_value`` à la propriété ``value`` du nœud " "``TextureProgress``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 #, fuzzy msgid "" "``str`` is a built-in function that converts about any value to text. " @@ -9289,7 +9300,7 @@ msgstr "" "``text`` de ``Number`` n 'accepte que les chaîne de caractères, on ne peut " "pas assigner ``new_value`` directement" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 #, fuzzy msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " @@ -9302,19 +9313,19 @@ msgstr "" "``Number`` avec la bonne valeur.\n" "Lancez le jeu avec F5: la barre de vie se mets à jour à chaque coup!" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 #, fuzzy msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "A chaque coup, le nombre et la barre de vie se mettes à jour" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 #, fuzzy msgid "Animate the loss of life with the Tween node" msgstr "Animer la perte de vie avec un nœud Tween" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 #, fuzzy msgid "" "Our interface is functional, but it could use some animation. That's a good " @@ -9330,7 +9341,7 @@ msgstr "" "deux état sur une certaine durée. par exemple il peut animer la barre de vie " "``TextureProgress`` entre deux états, avant et après le coup." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 #, fuzzy msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " @@ -9341,7 +9352,7 @@ msgstr "" "variable ``tween`` dans notre script. On peut maintenant l'utiliser, et " "faire quelques modifications dans notre fonction ``update_health``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 #, fuzzy msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " @@ -9350,42 +9361,42 @@ msgstr "" "Nous utiliserons la méthode ``interpolate_property`` du nœud ``Tween``. Elle " "prends sept paramètres :" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 #, fuzzy msgid "A reference to the node who owns the property to animate" msgstr "Le nœud dont la propriété est à animer" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 #, fuzzy msgid "The property's identifier as a string" msgstr "Le nom de la propriété en chaîne de caractère" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 #, fuzzy msgid "The starting value" msgstr "La valeur initiale" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 #, fuzzy msgid "The end value" msgstr "La valeur finale" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 #, fuzzy msgid "The animation's duration in seconds" msgstr "La durée de l'animation en seconde" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 #, fuzzy msgid "The type of the transition" msgstr "Le type de transition" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 #, fuzzy msgid "The easing to use in combination with the equation." msgstr "Le \"easing\" à utiliser." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 #, fuzzy msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " @@ -9395,7 +9406,7 @@ msgstr "" "d'easing <#>`__. Cela permet de contrôler l'évolution de la valeur entre la " "valeur initiale et finale." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 #, fuzzy msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " @@ -9411,7 +9422,7 @@ msgstr "" "texte directement. Nous allons l'utiliser pour animer une nouvelle variable " "``GUI`` nommée ``animated_health``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 #, fuzzy msgid "" "At the top of the script, define a new variable, name it " @@ -9425,12 +9436,12 @@ msgstr "" "``update_health`` et effacez son contenu. Animons la valeur \"animated_health" "\". Appelez la fonction``interpolate_property`` du nœud ``Tween`` :" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 #, fuzzy msgid "Let's break down the call:" msgstr "Décomposons l'appel :" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 #, fuzzy msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " @@ -9443,7 +9454,7 @@ msgstr "" "propriété en chaîne de caractère. C'est pour cela qu'on l'écrit ``" "\"animated_health\"``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 #, fuzzy msgid "" "The starting point is the current value the bar's at. We still have to code " @@ -9457,7 +9468,7 @@ msgstr "" "``update_health``. \n" "Et ``0.6`` est la durée de l'animation en seconde." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 #, fuzzy msgid "" "The last two arguments are constants from the ``Tween`` class. " @@ -9470,7 +9481,7 @@ msgstr "" "d'action sur une animation linéaire, mais on doit donner un dernier argument " "sinon on aura une erreur." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 #, fuzzy msgid "" "The animation will not play until we activated the ``Tween`` node with " @@ -9481,7 +9492,7 @@ msgstr "" "``Tween``sera activé avec ``tween.start()``. On peut lancé l'animation une " "fois si le nœud n'est pas actif, en ajoutant ce code à la dernière ligne :" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 #, fuzzy msgid "" "Although we could animate the `health` property on the `Player`, we " @@ -9499,12 +9510,12 @@ msgstr "" "animer à l'aide d'un script, mais pour lancer autrement l'animation, il " "faudrait utiliser le nœud `AnimationPlayer`." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 #, fuzzy msgid "Assign the animated\\_health to the LifeBar" msgstr "Relier animated\\_health et la barre de vie" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 #, fuzzy msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " @@ -9513,12 +9524,12 @@ msgstr "" "Notre variable ``animated_health`` est maintenant animée mais elle n'est pas " "relier aux nœuds ``Bar``et ``Number``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 #, fuzzy msgid "So far, the update\\_health method looks like this:" msgstr "Jusqu'à maintenant, la fonction update\\_health ressemble à cela:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " @@ -9529,7 +9540,7 @@ msgstr "" "pour mettre à jour les noeuds ``Number`` et ``TextureProgress`` comme avant, " "à l'intérieur de ``_process``:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." @@ -9537,7 +9548,7 @@ msgstr "" "`number_label` et `bar` sont des variables qui stocke les références vers " "les noeuds `Number` et `TextureProgress`." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 #, fuzzy msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " @@ -9548,12 +9559,12 @@ msgstr "" "décimal et fait n'importe quoi. En considérant le style du jeu, ça serait " "bien pour la barre de vie de s'animer d'une façon plus saccadé." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 #, fuzzy msgid "The animation is smooth but the number is broken" msgstr "L'animation est fluide mais le nombre est cassé" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 #, fuzzy msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " @@ -9564,18 +9575,18 @@ msgstr "" "``animated_health``. Utiliser une varible locale ``round_value`` pour " "stocker l'arrondi. Puis assigner la à ``number_label.text`` et ``bar.value``:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 #, fuzzy msgid "Try the game again to see a nice blocky animation." msgstr "" "Essayez le jeu une nouvelle fois pour voir une belle animation groupée." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 #, fuzzy msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "En arrondissant animated\\_health, on a fait d'une pierre deux coups" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 #, fuzzy msgid "" "Every time the player takes a hit, the ``GUI`` calls " @@ -9593,12 +9604,12 @@ msgstr "" "Il ne faut pas oublier, que l'animation de la barre de vie est une belle " "illusion. Si le joueur prends 3 dégâts, c'est immédiat." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 #, fuzzy msgid "Fade the bar when the Player dies" msgstr "Fais un fondu de la barre quand le joueur meurt" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 #, fuzzy msgid "" "When the green character dies, it plays a death animation and fades out. At " @@ -9611,7 +9622,7 @@ msgstr "" "la barre quand le personnage meurt. On réutilisera le nœud ``Tween`` " "puisqu'il peut gérer plusieurs animations en parallèle." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 #, fuzzy msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " @@ -9624,18 +9635,18 @@ msgstr "" "l'espace de travail 2D. Sélectionner le nœud ``Player``dans le dock des " "scène et cliquer dans l'inspecteur sur l'onglet Node." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 #, fuzzy msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" "Trouver et sélectionner le signal ``died``, et cliquer sur le bouton Connect." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 #, fuzzy msgid "The signal should already have the Enemy connected to it" msgstr "Ce signal est déjà connecté à l’ennemi." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 #, fuzzy msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " @@ -9649,40 +9660,40 @@ msgstr "" "Laisser l'option Make Function activé et cliquer sur Connect au bas de la " "fenêtre. Cela vous emmènera sur le script ``GUI.gd``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 #, fuzzy msgid "You should get these values in the Connecting Signal window" msgstr "" "Vous devriez avoir ces valeurs dans la fenêtre de connexion des signaux" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -9691,20 +9702,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -9712,15 +9723,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -9875,7 +9886,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -9915,7 +9926,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -9959,7 +9970,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -9983,7 +9994,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -10019,7 +10030,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -10039,14 +10050,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -10056,11 +10067,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -10068,7 +10079,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -10082,7 +10093,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -10097,7 +10108,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -10221,7 +10232,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -10263,8 +10274,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -10298,7 +10309,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -10328,9 +10339,10 @@ msgstr "" "utilisations importantes :" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 +#, fuzzy msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" "Elle contient la racine :ref:`Viewport `, à laquelle une " @@ -10339,16 +10351,18 @@ msgstr "" "d'informations sur ça par la suite)" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 +#, fuzzy msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" "Elle contient des informations sur les groupes et permet d'appeler tous les " "nœuds d'un groupe ou d'obtenir une liste de ceux-ci." #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 +#, fuzzy msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" "Elle contient certaines fonctionnalités d'état global, comme le réglage du " @@ -10377,10 +10391,11 @@ msgstr "" "A partir d'un nœud, elle peut être obtenu de deux manières différentes :" #: ../../docs/getting_started/step_by_step/scene_tree.rst:88 +#, fuzzy msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" "Ce nœud contient la vue principale, tout ce qui est un enfant d'un :ref:" @@ -10412,8 +10427,9 @@ msgstr "" "il fait partie de l'arborescence des scènes." #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 +#, fuzzy msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" "Cela signifie que, comme expliqué dans les tutoriels précédents, il recevra " @@ -10437,8 +10453,9 @@ msgid "Tree order" msgstr "Ordre de l'arborescence" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 +#, fuzzy msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -10458,10 +10475,11 @@ msgid "A scene is loaded from disk or created by scripting." msgstr "Une scène est chargée à partir du disque ou créée par un script." #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 +#, fuzzy msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" "Le nœud racine de cette scène (une seule racine, vous souvenez-vous ?) est " "ajouté soit comme un enfant de la fenêtre d'affichage Viewport \"racine" @@ -10505,7 +10523,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -10676,7 +10694,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -10686,25 +10704,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -10728,67 +10746,67 @@ msgstr "" "utilisateur de Unity, et vise à vous aider à transiter de votre expérience " "de Unity vers le monde de Godot." -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "Différences" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "Unity" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "Godot" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Licence" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" "Propriétaire, fermé, licence gratuite avec une limite de revenus et des " "restrictions d’usage" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "Licence MIT, libre et open source sans aucune restriction" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "OS (éditeur)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "Windows, macOS, Linux (non-official and non-supported)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "Windows, macOS, X11 (Linux, \\*BSD)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "OS (export)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "**Bureau :** Windows, macOS, Linux" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "**Mobile :** Android, iOS, Windows Phone, Tizen" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "**Web :** WebAssembly or asm.js" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "**Consoles :** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" @@ -10796,43 +10814,43 @@ msgstr "" "**VR :** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "**TV :** Android TV, Samsung SMART TV, tvOS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "**Desktop :** Windows, macOS, X11" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "**Mobile :** Android, iOS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "**Web :** WebAssembly" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "**Console :** Voir :ref:`doc_consoles`" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "**VR :** Oculus Rift, SteamVR" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "Composant/Scène (GameObject > Composant)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "Prefabs" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" @@ -10840,78 +10858,78 @@ msgstr "" ":ref:`Un arbre de scènes et des nœuds `, permettant " "aux scènes d’être imbriquées ou d’hériter d’autres scènes" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "Outils de tierce partie" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "Visual Studio ou VS Code" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr ":ref:`Les éditeurs externes sont possibles `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" ":ref:`La SDK Android pour l’export Android `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "Fonctionnalités de tueurs" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "Immense communauté" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "Grande boutique en ligne de ressources" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr ":ref:`Pipeline d’animation `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr ":ref:`Facilité d’écriture de Shaders `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "Débogage sur appareil" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "L’éditeur" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -10919,17 +10937,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -10937,139 +10955,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "Les briques" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "Les pièces" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "Le joueur" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "Les ennemis" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -11079,7 +11097,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -11089,70 +11107,70 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 #, fuzzy msgid "Project organization" msgstr "Organisation de projet" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -11160,125 +11178,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "Correspondance de glossaire" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -11286,7 +11304,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -11310,7 +11328,7 @@ msgstr "Chemin" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -11347,79 +11365,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "Éxécuter le jeu" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "Débogage" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -11427,36 +11445,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "Éxécuter un script" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -15579,12 +15597,13 @@ msgstr "" "Cliquer droit sur la variable vous permet de configurer ses propriétés :" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 +#, fuzzy msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" "Comme on peut le voir ci-dessus, le type et la valeur initiale de la " "variable peuvent être modifiés, ainsi que certains indices de propriété " @@ -17012,7 +17031,7 @@ msgstr "get_scale()" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "Scale" @@ -17781,6 +17800,262 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +#, fuzzy +msgid "Godot-Blender-Exporter" +msgstr "Importeur de scènes Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +#, fuzzy +msgid "Export of Blender materials" +msgstr "Exporter les modèles" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Il n'y a aucune restriction d'utilisation de Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +#, fuzzy +msgid "Physics Properties" +msgstr "Propriétés d’un nœud" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "Par type" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +#, fuzzy +msgid "There are the following caveats:" +msgstr "Avec les éléments suivants :" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "Gestion des assets" @@ -18730,136 +19005,151 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 +#, fuzzy +msgid "Exporting ESCN files from Blender" +msgstr "Exportation de fichiers DAE de Blender" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 +msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 msgid "Import workflows" msgstr "Processus d’importation" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -18867,28 +19157,28 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "Compresser" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." @@ -18896,11 +19186,11 @@ msgstr "" "Fait utiliser des nombres de moindre précision dans plusieurs aspects des " "maillages pour sauver de l’espace." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "Ceux-ci sont :" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." @@ -18908,7 +19198,7 @@ msgstr "" "Matrice de transformation (position, rotation, and échelle) : " "flottant 32-bit vers entier signé 16-bit." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." @@ -18916,7 +19206,7 @@ msgstr "" "Vertex : flottant 32-bit " "vers entier signé 16-bit." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." @@ -18924,7 +19214,7 @@ msgstr "" "Normales : flottant 32-" "bit vers entier non-signé 32-bit." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." @@ -18932,7 +19222,7 @@ msgstr "" "Tangentes : flottant 32-" "bit vers entier non-signé 32-bit." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." @@ -18940,7 +19230,7 @@ msgstr "" "Couleur des vertex : flottant " "32-bit vers entier non-signé 32-bit." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." @@ -18948,7 +19238,7 @@ msgstr "" "UV : flottant 32-" "bit vers entier non-signé 32-bit." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." @@ -18956,7 +19246,7 @@ msgstr "" "UV2 : flottant 32-" "bit vers entier non-signé 32-bit." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." @@ -18964,7 +19254,7 @@ msgstr "" "Poids des vertex : flottant 32-" "bit vers entier non-signé 16-bit." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." @@ -18972,7 +19262,7 @@ msgstr "" "Squelette d’armature : " "flottant 32-bit vers entier non-signé 16-bit." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." @@ -18981,18 +19271,18 @@ msgstr "" "flottant 32-bit vers entier non-signé 16 ou 32-bit selon le nombre " "d’éléments." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "Information supplémentaire :" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" "UV2 = le deuxième canal UV for les textures de détail et les textures de " "lightmap précalculé." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." @@ -19000,7 +19290,7 @@ msgstr "" "Indices de tableau = Un tableau de nombres qui numérote chaque élément des " "tableaux ci-dessus, ç-à-d. qu’il numérote les vertex et les normales." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -19009,15 +19299,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "Maillages" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "Vérifier les tangentes" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -19025,24 +19315,24 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "Fichiers externes" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." @@ -19050,11 +19340,11 @@ msgstr "" "Les maillages générés et les matériels peuvent être optionnellement stocké " "dans un sous-répertoire nommé d’après la scène." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "Options d’animation" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -19062,15 +19352,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "L'import d'animation est activé par défaut." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "IPS" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -19083,11 +19373,11 @@ msgstr "" "par seconde utilisées pour les éditer. Ne pas le faire peut entraîner des " "saccades minimes." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "Script de filtrage" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " @@ -19097,7 +19387,7 @@ msgstr "" "pour décider quelles pistes de quelles animations doivent être conservées. " "(@TODO ceci a besoin de documentation)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " @@ -19108,11 +19398,11 @@ msgstr "" "d'ajouter des pistes personnalisées aux animations et de les conserver après " "une réimportation." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "Optimiseur" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " @@ -19123,11 +19413,11 @@ msgstr "" "devrait toujours être activée, à moins que vous ne soupçonniez qu'elle " "pourrait casser une animation donnée." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "Clips" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 #, fuzzy msgid "" "It is possible to specify multiple animations from a single timeline as " @@ -19139,11 +19429,11 @@ msgstr "" "jusqu'à quelle image chaque clip doit être pris (et, bien sûr, n'oubliez pas " "de spécifier l'option IPS ci-dessus)." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "Héritage de scène" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 #, fuzzy msgid "" "In many cases, it may be desired to do modifications to the imported scene. " @@ -19156,7 +19446,7 @@ msgstr "" "ressource source change (fichier source .dae, .gltf, .obj réexporté à partir " "d'une application de modélisation 3D), Godot réimporte la scène entière." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 #, fuzzy msgid "" "It is possible, however, to do local modifications by using *Scene " @@ -19167,19 +19457,19 @@ msgstr "" "l'*héritage de scène*. Essayez simplement d'ouvrir la scène importée et la " "boîte de dialogue suivante apparaîtra :" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" "Dans les scènes héritées, les seules limitations pour les modifications " "sont :" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" "Les nœuds ne peuvent pas être supprimés (mais peuvent être ajoutés n'importe " "où)." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" @@ -19187,15 +19477,15 @@ msgstr "" "Les sous-ressources ne peuvent pas être éditées (sauvegardez-les en externe " "comme décrit ci-dessus)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "Sinon, tout est permis !" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "Conseils pour l'importation" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" @@ -19203,15 +19493,15 @@ msgstr "" "Souvent, lors de l'édition d'une scène, il y a des tâches communes qui " "doivent être effectuées après l'exportation :" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "Ajout de la détection de collision aux objets :" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "Réglage des objets comme maillages de navigation" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" @@ -19219,7 +19509,7 @@ msgstr "" "Supprimer les nœuds qui ne sont pas utilisés dans le moteur de jeu (comme " "les lumières spécifiques utilisées pour la modélisation)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " @@ -19230,11 +19520,11 @@ msgstr "" "3D. Lors de l'importation, Godot les détectera et effectuera des actions " "automatiquement :" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "Supprimer les nœuds (-noimp)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 #, fuzzy msgid "" "Node names that have this suffix will be removed at import time, no matter " @@ -19244,11 +19534,11 @@ msgstr "" "l'importation, quel que soit leur type. Ils n'apparaîtront pas dans la scène " "importée." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "Créer des collisions (-col, -colonly, -colonly, -convcolonly)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." @@ -19257,7 +19547,7 @@ msgstr "" "détectée, un nœud de collision statique enfant sera ajouté, utilisant la " "même géométrie que le maillage." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." @@ -19265,7 +19555,7 @@ msgstr "" "Cependant, il arrive souvent que la géométrie visuelle soit trop complexe ou " "trop peu lisse pour les collisions, ce qui finit par ne pas bien fonctionner." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " @@ -19276,7 +19566,7 @@ msgstr "" "`class_staticbody` à la place. Cela permet de séparer le maillage visuel et " "la collision réelle." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." @@ -19284,7 +19574,7 @@ msgstr "" "L'option \"-convcolonly\" créera :ref:`class_convexpolygonshape` au lieu de :" "ref:`class_concavepolygonshape`." -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -19296,44 +19586,44 @@ msgstr "" "noeud de collision en tant qu'enfant. Le noeud Collision aura une des formes " "prédéfinies, en fonction du type de dessin vide du Blender :" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "Une flèche simple créera une :ref:`class_rayshape`" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "Un cube créera une :ref:`class_boxshape`" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "Une image créera une :ref:`class_planeshape`" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -21686,7 +21976,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -21711,8 +22001,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -21747,7 +22037,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -21792,16 +22082,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -21897,7 +22187,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -22026,7 +22316,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -22166,7 +22456,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -22181,7 +22471,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -22281,44 +22571,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -22327,17 +22617,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -22349,7 +22639,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -22361,25 +22651,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -22387,61 +22677,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -22452,29 +22742,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Outils" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -22591,9 +22881,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -22602,8 +22892,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -22842,8 +23132,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -23102,7 +23392,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -23150,7 +23440,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -23288,7 +23578,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -23321,10 +23611,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -23757,16 +24043,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -23809,6 +24095,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -24132,8 +24419,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -24147,14 +24434,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -24186,67 +24473,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "Taille fixe" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "Couleur de vertex" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "Utiliser comme albedo" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "Est SRGB" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -24255,334 +24542,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "Mode diffus" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "**Lambert :** n’est pas affecté par la dureté." -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "Mode spéculaire" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "Mode de fusion" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "Albedo" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "Métallique" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "Dureté" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "Émission" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -24590,11 +24877,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -24603,30 +24890,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -24634,11 +24921,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -24648,11 +24935,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Profondeur" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -24661,66 +24948,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -24728,38 +25015,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -24770,13 +25057,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -24819,8 +25106,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -24831,7 +25118,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -24859,56 +25146,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -24916,26 +25203,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -24943,23 +25230,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -24968,129 +25255,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -25098,17 +25384,17 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "**Angle** : L’angle d’ouverture de la lumière" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." @@ -25116,95 +25402,95 @@ msgstr "" "**Atténuation d’angle**: l’atténuation de cône, qui aide à adoucir les bords " "du cône." -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -25234,61 +25520,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -25296,7 +25583,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -25304,42 +25591,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -25347,31 +25634,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -25386,186 +25673,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -25579,38 +25866,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -25619,44 +25906,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -25664,27 +25951,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -25692,7 +25979,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -25700,13 +25987,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -25715,113 +26002,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -25829,110 +26116,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -25940,12 +26227,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -25958,213 +26245,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -26172,38 +26459,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -26213,149 +26500,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -26363,143 +26650,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -26507,78 +26795,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -26619,10 +26907,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -26674,11 +26962,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -26714,7 +27002,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -26725,8 +27013,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -26741,23 +27029,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -26768,7 +27057,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -26982,9 +27271,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -26992,46 +27281,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -27039,92 +27329,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -27146,28 +27435,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -27176,7 +27464,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -27187,7 +27475,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -27197,50 +27485,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -27248,137 +27536,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -27386,31 +27683,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -27424,45 +27721,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -27470,68 +27772,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -27539,14 +27841,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -27559,8 +27861,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -27604,7 +27906,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -35098,14 +35400,14 @@ msgid "Audio" msgstr "Audio" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -35125,40 +35427,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -35166,37 +35472,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -35204,7 +35510,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -35214,79 +35520,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -35294,7 +35598,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -35306,39 +35610,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -35347,11 +35651,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -35359,51 +35663,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -35411,55 +35715,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -35468,11 +35772,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -35752,10 +36056,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -37615,1532 +37915,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr ":math:`(x,y)`" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "Représentation des rotations en 3D" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -45135,7 +43909,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -45527,226 +44301,345 @@ msgstr "Viewports" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -52200,9 +51093,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -52256,7 +51149,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -56885,6 +55778,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" @@ -61950,6 +60847,12 @@ msgstr "" "`Zeef Godot Engine: Un répertoire de ressources épuré par Andre Schmitz " "`_" +#~ msgid ":math:`(x,y)`" +#~ msgstr ":math:`(x,y)`" + +#~ msgid "Representation of rotations in 3D" +#~ msgstr "Représentation des rotations en 3D" + #~ msgid "Left: ``-60``" #~ msgstr "Left : ``-60``" diff --git a/weblate/he.po b/weblate/he.po index ba06601c0c..b47c4646eb 100644 --- a/weblate/he.po +++ b/weblate/he.po @@ -9,7 +9,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-04-20 14:38+0000\n" "Last-Translator: Yaron Shahrabani \n" "Language-Team: Hebrew ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3298,109 +3300,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3408,55 +3410,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3464,57 +3466,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3524,17 +3526,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3542,7 +3544,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3550,55 +3552,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3606,24 +3608,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6368,7 +6370,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6391,7 +6393,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6402,8 +6404,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6425,7 +6427,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6489,27 +6491,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6517,17 +6519,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6537,54 +6539,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6593,7 +6595,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6602,18 +6604,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6621,7 +6623,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6629,14 +6631,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6646,60 +6648,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6709,11 +6711,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6721,7 +6723,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6729,15 +6731,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6746,38 +6748,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6786,20 +6788,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6807,15 +6809,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6964,7 +6966,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7004,7 +7006,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7048,7 +7050,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7072,7 +7074,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7108,7 +7110,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7128,14 +7130,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7145,11 +7147,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7157,7 +7159,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7171,7 +7173,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7186,7 +7188,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7310,7 +7312,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7352,8 +7354,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7387,7 +7389,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7413,19 +7415,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7450,7 +7452,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7473,7 +7475,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7491,7 +7493,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7508,8 +7510,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7544,7 +7546,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7715,7 +7717,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7725,25 +7727,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7764,184 +7766,184 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "רישיון" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 #, fuzzy msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "X11 (לינוקס, /*BSD)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7949,17 +7951,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7967,139 +7969,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8109,7 +8111,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8119,69 +8121,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8189,125 +8191,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8315,7 +8317,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8339,7 +8341,7 @@ msgstr "נתיב" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8376,79 +8378,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8456,36 +8458,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11736,10 +11738,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12791,7 +12793,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13436,6 +13438,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "אין מגבלות שימוש בגודוט" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14337,136 +14590,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14474,113 +14741,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14589,15 +14856,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14605,34 +14872,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14640,15 +14907,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14656,51 +14923,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14708,102 +14975,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14811,44 +15078,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16757,7 +17024,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16782,8 +17049,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16818,7 +17085,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16863,16 +17130,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16968,7 +17235,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17097,7 +17364,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17237,7 +17504,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17252,7 +17519,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17352,44 +17619,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17398,17 +17665,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17420,7 +17687,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17432,25 +17699,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17458,61 +17725,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17523,29 +17790,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "כלים" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17662,9 +17929,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17673,8 +17940,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17913,8 +18180,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18173,7 +18440,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18221,7 +18488,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18359,7 +18626,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18392,10 +18659,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18828,16 +19091,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18880,6 +19143,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19203,8 +19467,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19218,14 +19482,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19257,67 +19521,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19326,334 +19590,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19661,11 +19925,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19674,30 +19938,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19705,11 +19969,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19719,11 +19983,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19732,66 +19996,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19799,38 +20063,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19841,13 +20105,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19890,8 +20154,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19902,7 +20166,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19930,56 +20194,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19987,26 +20251,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20014,23 +20278,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20039,129 +20303,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20169,111 +20432,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20303,61 +20566,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20365,7 +20629,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20373,42 +20637,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20416,31 +20680,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20455,186 +20719,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20648,38 +20912,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20688,44 +20952,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20733,27 +20997,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20761,7 +21025,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20769,13 +21033,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20784,113 +21048,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20898,110 +21162,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21009,12 +21273,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21027,213 +21291,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21241,38 +21505,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21282,149 +21546,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21432,143 +21696,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21576,78 +21841,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21688,10 +21953,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21743,11 +22008,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21783,7 +22048,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21794,8 +22059,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21810,23 +22075,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21837,7 +22103,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22051,9 +22317,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22061,46 +22327,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22108,92 +22375,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22215,28 +22481,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22245,7 +22510,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22256,7 +22521,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22266,50 +22531,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22317,137 +22582,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22455,31 +22729,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22493,45 +22767,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22539,68 +22818,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22608,14 +22887,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22628,8 +22907,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22673,7 +22952,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30152,14 +30431,14 @@ msgid "Audio" msgstr "שמע" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30179,40 +30458,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30220,37 +30503,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30258,7 +30541,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30268,79 +30551,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30348,7 +30629,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30360,39 +30641,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30401,11 +30682,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30413,51 +30694,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30465,55 +30746,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30522,11 +30803,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30806,10 +31087,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32668,1532 +32945,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40185,7 +38936,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40573,226 +39324,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47238,9 +46108,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47294,7 +46164,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51890,6 +50760,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/hu.po b/weblate/hu.po index e75cddf24f..89b80cb578 100644 --- a/weblate/hu.po +++ b/weblate/hu.po @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-17 16:39+0000\n" "Last-Translator: Árpád Horváth \n" "Language-Team: Hungarian ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3353,109 +3355,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3463,55 +3465,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3519,57 +3521,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3579,17 +3581,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3597,7 +3599,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3605,55 +3607,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "Részecskék" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3661,24 +3663,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6422,7 +6424,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6445,7 +6447,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6456,8 +6458,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6479,7 +6481,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6543,27 +6545,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6571,17 +6573,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6591,54 +6593,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6647,7 +6649,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6656,18 +6658,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6675,7 +6677,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6683,14 +6685,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6700,60 +6702,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6763,11 +6765,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6775,7 +6777,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6783,15 +6785,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6800,38 +6802,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6840,20 +6842,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6861,15 +6863,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7018,7 +7020,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7058,7 +7060,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7102,7 +7104,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7126,7 +7128,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7162,7 +7164,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7182,14 +7184,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7199,11 +7201,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7211,7 +7213,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7225,7 +7227,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7240,7 +7242,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7364,7 +7366,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7406,8 +7408,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7441,7 +7443,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7467,19 +7469,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7504,7 +7506,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7527,7 +7529,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7545,7 +7547,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7562,8 +7564,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7598,7 +7600,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7769,7 +7771,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7779,25 +7781,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7818,183 +7820,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Licenc" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8002,17 +8004,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8020,139 +8022,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8162,7 +8164,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8172,69 +8174,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8242,125 +8244,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8368,7 +8370,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8392,7 +8394,7 @@ msgstr "Útvonal" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8429,79 +8431,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8509,36 +8511,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11786,10 +11788,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12840,7 +12842,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13485,6 +13487,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Nincs felhasználási korlátozás a Godot-ra" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14386,136 +14639,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14523,113 +14790,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14638,15 +14905,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14654,34 +14921,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14689,15 +14956,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14705,51 +14972,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14757,102 +15024,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14860,44 +15127,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16806,7 +17073,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16831,8 +17098,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16867,7 +17134,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16912,16 +17179,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17017,7 +17284,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17146,7 +17413,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17286,7 +17553,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17301,7 +17568,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17401,44 +17668,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17447,17 +17714,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17469,7 +17736,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17481,25 +17748,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17507,61 +17774,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17572,29 +17839,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Eszközök" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17711,9 +17978,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17722,8 +17989,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17962,8 +18229,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18222,7 +18489,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18270,7 +18537,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18408,7 +18675,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18441,10 +18708,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18877,16 +19140,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18929,6 +19192,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19252,8 +19516,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19267,14 +19531,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19306,67 +19570,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19375,334 +19639,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19710,11 +19974,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19723,30 +19987,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19754,11 +20018,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19768,11 +20032,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Mélység" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19781,66 +20045,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19848,38 +20112,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19890,13 +20154,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19939,8 +20203,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19951,7 +20215,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19979,56 +20243,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20036,26 +20300,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20063,23 +20327,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20088,129 +20352,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20218,111 +20481,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20352,61 +20615,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20414,7 +20678,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20422,42 +20686,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20465,31 +20729,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20504,186 +20768,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20697,38 +20961,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20737,44 +21001,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20782,27 +21046,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20810,7 +21074,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20818,13 +21082,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20833,113 +21097,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20947,110 +21211,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21058,12 +21322,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21076,213 +21340,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21290,38 +21554,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21331,149 +21595,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21481,143 +21745,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21625,78 +21890,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21737,10 +22002,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21792,11 +22057,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21832,7 +22097,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21843,8 +22108,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21859,23 +22124,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21886,7 +22152,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22100,9 +22366,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22110,46 +22376,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22157,92 +22424,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22264,28 +22530,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22294,7 +22559,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22305,7 +22570,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22315,50 +22580,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22366,137 +22631,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22504,31 +22778,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22542,45 +22816,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22588,68 +22867,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22657,14 +22936,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22677,8 +22956,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22722,7 +23001,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30201,14 +30480,14 @@ msgid "Audio" msgstr "Hang" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30228,40 +30507,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30269,37 +30552,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30307,7 +30590,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30317,79 +30600,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30397,7 +30678,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30409,39 +30690,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30450,11 +30731,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30462,51 +30743,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30514,55 +30795,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30571,11 +30852,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30855,10 +31136,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32717,1532 +32994,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40234,7 +38985,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40622,226 +39373,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47287,9 +46157,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47343,7 +46213,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51939,6 +50809,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/id.po b/weblate/id.po index 958c2bee6c..049702a990 100644 --- a/weblate/id.po +++ b/weblate/id.po @@ -9,7 +9,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-05-31 16:39+0000\n" "Last-Translator: Reza Hidayat Bayu Prabowo \n" "Language-Team: Indonesian ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3298,109 +3300,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3408,55 +3410,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3464,57 +3466,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3524,17 +3526,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3542,7 +3544,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3550,55 +3552,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3606,24 +3608,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6367,7 +6369,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6390,7 +6392,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6401,8 +6403,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6424,7 +6426,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6488,27 +6490,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6516,17 +6518,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6536,54 +6538,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6592,7 +6594,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6601,18 +6603,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6620,7 +6622,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6628,14 +6630,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6645,60 +6647,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6708,11 +6710,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6720,7 +6722,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6728,15 +6730,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6745,38 +6747,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6785,20 +6787,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6806,15 +6808,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6963,7 +6965,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7003,7 +7005,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7047,7 +7049,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7071,7 +7073,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7107,7 +7109,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7127,14 +7129,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7144,11 +7146,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7156,7 +7158,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7170,7 +7172,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7185,7 +7187,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7309,7 +7311,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7351,8 +7353,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7386,7 +7388,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7412,19 +7414,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7449,7 +7451,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7472,7 +7474,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7490,7 +7492,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7507,8 +7509,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7543,7 +7545,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7714,7 +7716,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7724,25 +7726,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7763,183 +7765,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7947,17 +7949,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7965,139 +7967,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8107,7 +8109,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8117,69 +8119,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8187,125 +8189,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8313,7 +8315,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8337,7 +8339,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8374,79 +8376,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8454,36 +8456,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11731,10 +11733,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12785,7 +12787,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13430,6 +13432,256 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14331,136 +14583,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14468,113 +14734,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14583,15 +14849,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14599,34 +14865,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14634,15 +14900,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14650,51 +14916,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14702,102 +14968,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14805,44 +15071,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16751,7 +17017,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16776,8 +17042,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16812,7 +17078,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16857,16 +17123,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16962,7 +17228,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17091,7 +17357,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17231,7 +17497,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17246,7 +17512,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17346,44 +17612,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17392,17 +17658,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17414,7 +17680,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17426,25 +17692,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17452,61 +17718,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17517,29 +17783,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17656,9 +17922,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17667,8 +17933,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17907,8 +18173,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18167,7 +18433,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18215,7 +18481,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18353,7 +18619,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18386,10 +18652,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18822,16 +19084,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18874,6 +19136,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19197,8 +19460,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19212,14 +19475,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19251,67 +19514,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19320,334 +19583,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19655,11 +19918,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19668,30 +19931,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19699,11 +19962,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19713,11 +19976,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19726,66 +19989,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19793,38 +20056,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19835,13 +20098,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19884,8 +20147,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19896,7 +20159,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19924,56 +20187,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19981,26 +20244,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20008,23 +20271,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20033,129 +20296,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20163,111 +20425,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20297,61 +20559,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20359,7 +20622,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20367,42 +20630,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20410,31 +20673,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20449,186 +20712,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20642,38 +20905,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20682,44 +20945,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20727,27 +20990,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20755,7 +21018,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20763,13 +21026,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20778,113 +21041,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20892,110 +21155,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21003,12 +21266,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21021,213 +21284,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21235,38 +21498,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21276,149 +21539,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21426,143 +21689,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21570,78 +21834,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21682,10 +21946,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21737,11 +22001,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21777,7 +22041,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21788,8 +22052,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21804,23 +22068,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21831,7 +22096,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22045,9 +22310,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22055,46 +22320,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22102,92 +22368,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22209,28 +22474,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22239,7 +22503,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22250,7 +22514,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22260,50 +22524,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22311,137 +22575,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22449,31 +22722,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22487,45 +22760,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22533,68 +22811,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22602,14 +22880,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22622,8 +22900,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22667,7 +22945,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30146,14 +30424,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30173,40 +30451,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30214,37 +30496,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30252,7 +30534,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30262,79 +30544,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30342,7 +30622,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30354,39 +30634,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30395,11 +30675,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30407,51 +30687,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30459,55 +30739,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30516,11 +30796,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30800,10 +31080,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32662,1532 +32938,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40179,7 +38929,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40567,226 +39317,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47232,9 +46101,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47288,7 +46157,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51884,6 +50753,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/it.po b/weblate/it.po index b3e7b0b2e7..08693fc16a 100644 --- a/weblate/it.po +++ b/weblate/it.po @@ -17,7 +17,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-05-28 08:21+0000\n" "Last-Translator: Andrea Brunato \n" "Language-Team: Italian ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3614,109 +3618,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3724,55 +3728,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3780,57 +3784,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3840,17 +3844,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3858,7 +3862,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3866,55 +3870,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3922,24 +3926,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6683,7 +6687,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6706,7 +6710,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6717,8 +6721,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6740,7 +6744,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6804,27 +6808,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6832,17 +6836,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6852,54 +6856,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6908,7 +6912,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6917,18 +6921,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6936,7 +6940,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6944,14 +6948,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6961,60 +6965,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -7024,11 +7028,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -7036,7 +7040,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -7044,15 +7048,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -7061,38 +7065,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -7101,20 +7105,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -7122,15 +7126,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7279,7 +7283,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7319,7 +7323,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7363,7 +7367,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7387,7 +7391,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7423,7 +7427,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7443,14 +7447,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7460,11 +7464,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7472,7 +7476,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7486,7 +7490,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7501,7 +7505,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7625,7 +7629,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7667,8 +7671,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7702,7 +7706,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7728,19 +7732,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7765,7 +7769,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7788,7 +7792,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7806,7 +7810,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7823,8 +7827,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7859,7 +7863,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -8030,7 +8034,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -8040,25 +8044,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -8079,183 +8083,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "Windows, macOS, X11 (Linux, \\*BSD)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8263,17 +8267,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8281,139 +8285,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8423,7 +8427,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8433,69 +8437,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8503,125 +8507,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8629,7 +8633,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8653,7 +8657,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8690,79 +8694,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8770,36 +8774,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -12050,10 +12054,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -13104,7 +13108,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13749,6 +13753,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Non ci sono restrizioni di utilizzo per Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14650,136 +14905,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14787,113 +15056,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14902,15 +15171,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14918,34 +15187,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14953,15 +15222,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14969,51 +15238,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -15021,102 +15290,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -15124,44 +15393,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -17070,7 +17339,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -17095,8 +17364,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -17131,7 +17400,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -17176,16 +17445,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17281,7 +17550,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17410,7 +17679,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17550,7 +17819,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17565,7 +17834,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17665,44 +17934,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17711,17 +17980,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17733,7 +18002,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17745,25 +18014,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17771,61 +18040,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17836,29 +18105,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17975,9 +18244,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17986,8 +18255,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -18226,8 +18495,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18486,7 +18755,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18534,7 +18803,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18672,7 +18941,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18705,10 +18974,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -19141,16 +19406,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -19193,6 +19458,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19516,8 +19782,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19531,14 +19797,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19570,67 +19836,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19639,334 +19905,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19974,11 +20240,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19987,30 +20253,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -20018,11 +20284,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -20032,11 +20298,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -20045,66 +20311,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -20112,38 +20378,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -20154,13 +20420,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -20203,8 +20469,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -20215,7 +20481,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -20243,56 +20509,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20300,26 +20566,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20327,23 +20593,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20352,129 +20618,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20482,111 +20747,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20616,61 +20881,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20678,7 +20944,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20686,42 +20952,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20729,31 +20995,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20768,186 +21034,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20961,38 +21227,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -21001,44 +21267,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -21046,27 +21312,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -21074,7 +21340,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -21082,13 +21348,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -21097,113 +21363,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -21211,110 +21477,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21322,12 +21588,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21340,213 +21606,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21554,38 +21820,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21595,149 +21861,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21745,143 +22011,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21889,78 +22156,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -22001,10 +22268,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -22056,11 +22323,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -22096,7 +22363,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -22107,8 +22374,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -22123,23 +22390,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -22150,7 +22418,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22364,9 +22632,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22374,46 +22642,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22421,92 +22690,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22528,28 +22796,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22558,7 +22825,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22569,7 +22836,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22579,50 +22846,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22630,137 +22897,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22768,31 +23044,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22806,45 +23082,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22852,68 +23133,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22921,14 +23202,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22941,8 +23222,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22986,7 +23267,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30465,14 +30746,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30492,40 +30773,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30533,37 +30818,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30571,7 +30856,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30581,79 +30866,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30661,7 +30944,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30673,39 +30956,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30714,11 +30997,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30726,51 +31009,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30778,55 +31061,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30835,11 +31118,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -31119,10 +31402,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32981,1532 +33260,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40498,7 +39251,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40886,226 +39639,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47551,9 +46423,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47607,7 +46479,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -52203,6 +51075,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/ja.po b/weblate/ja.po index 021a3499f6..724c8e8bc1 100644 --- a/weblate/ja.po +++ b/weblate/ja.po @@ -10,7 +10,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-15 22:40+0000\n" "Last-Translator: yu tang <0011solo@gmail.com>\n" "Language-Team: Japanese ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3280,109 +3282,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3390,55 +3392,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3446,57 +3448,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3506,17 +3508,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3524,7 +3526,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3532,55 +3534,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3588,24 +3590,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6350,7 +6352,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6373,7 +6375,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6384,8 +6386,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6407,7 +6409,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6471,27 +6473,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6499,17 +6501,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6519,54 +6521,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6575,7 +6577,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6584,18 +6586,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6603,7 +6605,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6611,14 +6613,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6628,60 +6630,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6691,11 +6693,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6703,7 +6705,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6711,15 +6713,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6728,38 +6730,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6768,20 +6770,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6789,15 +6791,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6946,7 +6948,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -6986,7 +6988,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7030,7 +7032,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7054,7 +7056,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7090,7 +7092,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7110,14 +7112,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7127,11 +7129,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7139,7 +7141,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7153,7 +7155,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7168,7 +7170,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7292,7 +7294,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7334,8 +7336,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7369,7 +7371,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7395,19 +7397,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7432,7 +7434,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7455,7 +7457,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7473,7 +7475,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7490,8 +7492,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7526,7 +7528,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7697,7 +7699,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7707,25 +7709,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7746,183 +7748,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "ライセンス" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7930,17 +7932,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7948,139 +7950,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8090,7 +8092,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8100,69 +8102,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8170,125 +8172,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8296,7 +8298,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8320,7 +8322,7 @@ msgstr "パス" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8357,79 +8359,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8437,36 +8439,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11714,10 +11716,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12768,7 +12770,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13413,6 +13415,256 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14314,136 +14566,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14451,113 +14717,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14566,15 +14832,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14582,34 +14848,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14617,15 +14883,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14633,51 +14899,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14685,102 +14951,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14788,44 +15054,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16734,7 +17000,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16759,8 +17025,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16795,7 +17061,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16840,16 +17106,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16945,7 +17211,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17074,7 +17340,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17214,7 +17480,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17229,7 +17495,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17329,44 +17595,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17375,17 +17641,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17397,7 +17663,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17409,25 +17675,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17435,61 +17701,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17500,29 +17766,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17639,9 +17905,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17650,8 +17916,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17890,8 +18156,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18150,7 +18416,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18198,7 +18464,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18336,7 +18602,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18369,10 +18635,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18805,16 +19067,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18857,6 +19119,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19180,8 +19443,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19195,14 +19458,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19234,67 +19497,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19303,334 +19566,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19638,11 +19901,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19651,30 +19914,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19682,11 +19945,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19696,11 +19959,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "奥行き" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19709,66 +19972,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19776,38 +20039,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19818,13 +20081,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19867,8 +20130,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19879,7 +20142,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19907,56 +20170,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19964,26 +20227,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -19991,23 +20254,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20016,129 +20279,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20146,111 +20408,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20280,61 +20542,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20342,7 +20605,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20350,42 +20613,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20393,31 +20656,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20432,186 +20695,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20625,38 +20888,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20665,44 +20928,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20710,27 +20973,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20738,7 +21001,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20746,13 +21009,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20761,113 +21024,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20875,110 +21138,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -20986,12 +21249,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21004,213 +21267,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21218,38 +21481,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21259,149 +21522,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21409,143 +21672,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21553,78 +21817,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21665,10 +21929,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21720,11 +21984,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21760,7 +22024,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21771,8 +22035,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21787,23 +22051,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21814,7 +22079,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22028,9 +22293,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22038,46 +22303,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22085,92 +22351,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22192,28 +22457,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22222,7 +22486,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22233,7 +22497,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22243,50 +22507,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22294,137 +22558,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22432,31 +22705,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22470,45 +22743,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22516,68 +22794,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22585,14 +22863,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22605,8 +22883,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22650,7 +22928,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30129,14 +30407,14 @@ msgid "Audio" msgstr "オーディオ" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30156,40 +30434,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30197,37 +30479,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30235,7 +30517,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30245,79 +30527,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30325,7 +30605,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30337,39 +30617,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30378,11 +30658,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30390,51 +30670,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30442,55 +30722,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30499,11 +30779,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30783,10 +31063,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32645,1532 +32921,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40162,7 +38912,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40550,226 +39300,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47215,9 +46084,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47271,7 +46140,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51867,6 +50736,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/ko.po b/weblate/ko.po index 9e61b70ada..85b31e21bd 100644 --- a/weblate/ko.po +++ b/weblate/ko.po @@ -16,7 +16,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-18 06:42+0000\n" "Last-Translator: 송태섭 \n" "Language-Team: Korean ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3953,109 +3958,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -4063,55 +4068,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -4119,57 +4124,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -4179,17 +4184,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -4197,7 +4202,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -4205,55 +4210,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "파티클" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -4261,24 +4266,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -7022,7 +7027,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -7045,7 +7050,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -7056,8 +7061,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -7079,7 +7084,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -7143,27 +7148,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -7171,17 +7176,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -7191,54 +7196,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -7247,7 +7252,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -7256,18 +7261,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -7275,7 +7280,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -7283,14 +7288,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -7300,60 +7305,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -7363,11 +7368,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -7375,7 +7380,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -7383,15 +7388,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -7400,38 +7405,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -7440,20 +7445,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -7461,15 +7466,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7618,7 +7623,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7658,7 +7663,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7702,7 +7707,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7726,7 +7731,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7762,7 +7767,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7782,14 +7787,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7799,11 +7804,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7811,7 +7816,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7825,7 +7830,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7840,7 +7845,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7964,7 +7969,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -8006,8 +8011,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -8041,7 +8046,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -8067,19 +8072,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -8104,7 +8109,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -8127,7 +8132,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -8145,7 +8150,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -8162,8 +8167,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -8198,7 +8203,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -8369,7 +8374,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -8379,25 +8384,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -8418,183 +8423,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "라이선스" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "윈도우, 맥OS, X11 (리눅스, \\*BSD)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8602,17 +8607,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8620,139 +8625,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8762,7 +8767,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8772,69 +8777,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8842,125 +8847,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8968,7 +8973,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8992,7 +8997,7 @@ msgstr "경로" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -9029,79 +9034,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -9109,36 +9114,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -12446,10 +12451,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -13500,7 +13505,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -14145,6 +14150,258 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Godot를 사용하는 데 제약이 없습니다" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "타입" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -15046,136 +15303,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -15183,113 +15454,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -15298,15 +15569,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -15314,34 +15585,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -15349,15 +15620,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "초당 프레임" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -15365,51 +15636,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -15417,102 +15688,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -15520,44 +15791,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -17466,7 +17737,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -17491,8 +17762,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -17527,7 +17798,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -17572,16 +17843,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17677,7 +17948,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17806,7 +18077,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17946,7 +18217,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17961,7 +18232,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -18061,44 +18332,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -18107,17 +18378,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -18129,7 +18400,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -18141,25 +18412,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -18167,61 +18438,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -18232,29 +18503,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "도구" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -18371,9 +18642,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -18382,8 +18653,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -18622,8 +18893,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18882,7 +19153,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18930,7 +19201,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -19068,7 +19339,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -19101,10 +19372,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -19537,16 +19804,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -19589,6 +19856,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19912,8 +20180,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19927,14 +20195,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19966,67 +20234,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -20035,334 +20303,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -20370,11 +20638,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -20383,30 +20651,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -20414,11 +20682,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -20428,11 +20696,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "깊이" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -20441,66 +20709,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -20508,38 +20776,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -20550,13 +20818,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -20599,8 +20867,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -20611,7 +20879,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -20639,56 +20907,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20696,26 +20964,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20723,23 +20991,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20748,129 +21016,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20878,111 +21145,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -21012,61 +21279,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -21074,7 +21342,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -21082,42 +21350,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -21125,31 +21393,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -21164,186 +21432,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -21357,38 +21625,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -21397,44 +21665,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -21442,27 +21710,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -21470,7 +21738,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -21478,13 +21746,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -21493,113 +21761,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -21607,110 +21875,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21718,12 +21986,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21736,213 +22004,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21950,38 +22218,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21991,149 +22259,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -22141,143 +22409,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -22285,78 +22554,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -22397,10 +22666,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -22452,11 +22721,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -22492,7 +22761,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -22503,8 +22772,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -22519,23 +22788,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -22546,7 +22816,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22760,9 +23030,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22770,46 +23040,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22817,92 +23088,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22924,28 +23194,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22954,7 +23223,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22965,7 +23234,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22975,50 +23244,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -23026,137 +23295,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -23164,31 +23442,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -23202,45 +23480,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -23248,68 +23531,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -23317,14 +23600,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -23337,8 +23620,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -23382,7 +23665,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30861,14 +31144,14 @@ msgid "Audio" msgstr "오디오" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30888,40 +31171,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30929,37 +31216,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30967,7 +31254,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30977,79 +31264,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -31057,7 +31342,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -31069,39 +31354,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -31110,11 +31395,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -31122,51 +31407,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -31174,55 +31459,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -31231,11 +31516,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -31515,10 +31800,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -33377,1532 +33658,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40894,7 +39649,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -41282,226 +40037,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47947,9 +46821,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -48003,7 +46877,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -52599,6 +51473,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/lt.po b/weblate/lt.po index ad66445640..e9df984541 100644 --- a/weblate/lt.po +++ b/weblate/lt.po @@ -10,7 +10,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-12 09:40+0000\n" "Last-Translator: Kornelijus \n" "Language-Team: Lithuanian ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3257,109 +3259,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3367,55 +3369,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3423,57 +3425,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3483,17 +3485,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3501,7 +3503,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3509,55 +3511,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3565,24 +3567,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6326,7 +6328,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6349,7 +6351,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6360,8 +6362,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6383,7 +6385,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6447,27 +6449,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6475,17 +6477,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6495,54 +6497,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6551,7 +6553,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6560,18 +6562,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6579,7 +6581,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6587,14 +6589,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6604,60 +6606,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6667,11 +6669,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6679,7 +6681,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6687,15 +6689,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6704,38 +6706,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6744,20 +6746,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6765,15 +6767,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6922,7 +6924,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -6962,7 +6964,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7006,7 +7008,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7030,7 +7032,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7066,7 +7068,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7086,14 +7088,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7103,11 +7105,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7115,7 +7117,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7129,7 +7131,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7144,7 +7146,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7268,7 +7270,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7310,8 +7312,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7345,7 +7347,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7371,19 +7373,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7408,7 +7410,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7431,7 +7433,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7449,7 +7451,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7466,8 +7468,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7502,7 +7504,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7673,7 +7675,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7683,25 +7685,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7722,183 +7724,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7906,17 +7908,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7924,139 +7926,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8066,7 +8068,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8076,69 +8078,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8146,125 +8148,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8272,7 +8274,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8296,7 +8298,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8333,79 +8335,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8413,36 +8415,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11690,10 +11692,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12744,7 +12746,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13389,6 +13391,256 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14290,136 +14542,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14427,113 +14693,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14542,15 +14808,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14558,34 +14824,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14593,15 +14859,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14609,51 +14875,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14661,102 +14927,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14764,44 +15030,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16710,7 +16976,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16735,8 +17001,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16771,7 +17037,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16816,16 +17082,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16921,7 +17187,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17050,7 +17316,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17190,7 +17456,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17205,7 +17471,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17305,44 +17571,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17351,17 +17617,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17373,7 +17639,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17385,25 +17651,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17411,61 +17677,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17476,29 +17742,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17615,9 +17881,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17626,8 +17892,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17866,8 +18132,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18126,7 +18392,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18174,7 +18440,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18312,7 +18578,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18345,10 +18611,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18781,16 +19043,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18833,6 +19095,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19156,8 +19419,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19171,14 +19434,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19210,67 +19473,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19279,334 +19542,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19614,11 +19877,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19627,30 +19890,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19658,11 +19921,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19672,11 +19935,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19685,66 +19948,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19752,38 +20015,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19794,13 +20057,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19843,8 +20106,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19855,7 +20118,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19883,56 +20146,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19940,26 +20203,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -19967,23 +20230,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -19992,129 +20255,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20122,111 +20384,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20256,61 +20518,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20318,7 +20581,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20326,42 +20589,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20369,31 +20632,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20408,186 +20671,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20601,38 +20864,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20641,44 +20904,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20686,27 +20949,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20714,7 +20977,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20722,13 +20985,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20737,113 +21000,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20851,110 +21114,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -20962,12 +21225,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -20980,213 +21243,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21194,38 +21457,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21235,149 +21498,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21385,143 +21648,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21529,78 +21793,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21641,10 +21905,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21696,11 +21960,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21736,7 +22000,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21747,8 +22011,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21763,23 +22027,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21790,7 +22055,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22004,9 +22269,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22014,46 +22279,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22061,92 +22327,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22168,28 +22433,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22198,7 +22462,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22209,7 +22473,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22219,50 +22483,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22270,137 +22534,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22408,31 +22681,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22446,45 +22719,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22492,68 +22770,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22561,14 +22839,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22581,8 +22859,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22626,7 +22904,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30105,14 +30383,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30132,40 +30410,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30173,37 +30455,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30211,7 +30493,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30221,79 +30503,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30301,7 +30581,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30313,39 +30593,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30354,11 +30634,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30366,51 +30646,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30418,55 +30698,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30475,11 +30755,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30759,10 +31039,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32621,1532 +32897,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40138,7 +38888,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40526,226 +39276,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47191,9 +46060,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47247,7 +46116,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51843,6 +50712,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/ms.po b/weblate/ms.po index a3c756b59d..207552683b 100644 --- a/weblate/ms.po +++ b/weblate/ms.po @@ -6,7 +6,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: Automatically generated\n" "Language-Team: Malay ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3239,109 +3241,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3349,55 +3351,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3405,57 +3407,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3465,17 +3467,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3483,7 +3485,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3491,55 +3493,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3547,24 +3549,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6308,7 +6310,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6331,7 +6333,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6342,8 +6344,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6365,7 +6367,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6429,27 +6431,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6457,17 +6459,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6477,54 +6479,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6533,7 +6535,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6542,18 +6544,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6561,7 +6563,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6569,14 +6571,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6586,60 +6588,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6649,11 +6651,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6661,7 +6663,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6669,15 +6671,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6686,38 +6688,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6726,20 +6728,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6747,15 +6749,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6904,7 +6906,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -6944,7 +6946,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -6988,7 +6990,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7012,7 +7014,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7048,7 +7050,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7068,14 +7070,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7085,11 +7087,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7097,7 +7099,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7111,7 +7113,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7126,7 +7128,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7250,7 +7252,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7292,8 +7294,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7327,7 +7329,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7353,19 +7355,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7390,7 +7392,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7413,7 +7415,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7431,7 +7433,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7448,8 +7450,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7484,7 +7486,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7655,7 +7657,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7665,25 +7667,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7704,183 +7706,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7888,17 +7890,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7906,139 +7908,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8048,7 +8050,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8058,69 +8060,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8128,125 +8130,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8254,7 +8256,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8278,7 +8280,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8315,79 +8317,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8395,36 +8397,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11672,10 +11674,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12726,7 +12728,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13371,6 +13373,256 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14272,136 +14524,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14409,113 +14675,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14524,15 +14790,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14540,34 +14806,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14575,15 +14841,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14591,51 +14857,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14643,102 +14909,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14746,44 +15012,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16692,7 +16958,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16717,8 +16983,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16753,7 +17019,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16798,16 +17064,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16903,7 +17169,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17032,7 +17298,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17172,7 +17438,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17187,7 +17453,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17287,44 +17553,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17333,17 +17599,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17355,7 +17621,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17367,25 +17633,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17393,61 +17659,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17458,29 +17724,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17597,9 +17863,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17608,8 +17874,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17848,8 +18114,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18108,7 +18374,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18156,7 +18422,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18294,7 +18560,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18327,10 +18593,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18763,16 +19025,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18815,6 +19077,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19138,8 +19401,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19153,14 +19416,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19192,67 +19455,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19261,334 +19524,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19596,11 +19859,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19609,30 +19872,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19640,11 +19903,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19654,11 +19917,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19667,66 +19930,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19734,38 +19997,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19776,13 +20039,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19825,8 +20088,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19837,7 +20100,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19865,56 +20128,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19922,26 +20185,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -19949,23 +20212,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -19974,129 +20237,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20104,111 +20366,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20238,61 +20500,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20300,7 +20563,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20308,42 +20571,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20351,31 +20614,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20390,186 +20653,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20583,38 +20846,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20623,44 +20886,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20668,27 +20931,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20696,7 +20959,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20704,13 +20967,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20719,113 +20982,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20833,110 +21096,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -20944,12 +21207,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -20962,213 +21225,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21176,38 +21439,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21217,149 +21480,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21367,143 +21630,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21511,78 +21775,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21623,10 +21887,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21678,11 +21942,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21718,7 +21982,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21729,8 +21993,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21745,23 +22009,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21772,7 +22037,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -21986,9 +22251,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -21996,46 +22261,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22043,92 +22309,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22150,28 +22415,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22180,7 +22444,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22191,7 +22455,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22201,50 +22465,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22252,137 +22516,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22390,31 +22663,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22428,45 +22701,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22474,68 +22752,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22543,14 +22821,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22563,8 +22841,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22608,7 +22886,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30087,14 +30365,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30114,40 +30392,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30155,37 +30437,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30193,7 +30475,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30203,79 +30485,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30283,7 +30563,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30295,39 +30575,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30336,11 +30616,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30348,51 +30628,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30400,55 +30680,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30457,11 +30737,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30741,10 +31021,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32603,1532 +32879,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40120,7 +38870,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40508,226 +39258,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47173,9 +46042,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47229,7 +46098,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51825,6 +50694,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/nb.po b/weblate/nb.po index 9c6c49e526..1ee6c9fc5f 100644 --- a/weblate/nb.po +++ b/weblate/nb.po @@ -9,7 +9,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-11 12:40+0000\n" "Last-Translator: Elias \n" "Language-Team: Norwegian Bokmål ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3247,109 +3249,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3357,55 +3359,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3413,57 +3415,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3473,17 +3475,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3491,7 +3493,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3499,55 +3501,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3555,24 +3557,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6316,7 +6318,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6339,7 +6341,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6350,8 +6352,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6373,7 +6375,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6437,27 +6439,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6465,17 +6467,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6485,54 +6487,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6541,7 +6543,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6550,18 +6552,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6569,7 +6571,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6577,14 +6579,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6594,60 +6596,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6657,11 +6659,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6669,7 +6671,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6677,15 +6679,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6694,38 +6696,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6734,20 +6736,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6755,15 +6757,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6912,7 +6914,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -6952,7 +6954,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -6996,7 +6998,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7020,7 +7022,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7056,7 +7058,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7076,14 +7078,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7093,11 +7095,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7105,7 +7107,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7119,7 +7121,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7134,7 +7136,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7258,7 +7260,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7300,8 +7302,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7335,7 +7337,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7361,19 +7363,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7398,7 +7400,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7421,7 +7423,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7439,7 +7441,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7456,8 +7458,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7492,7 +7494,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7663,7 +7665,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7673,25 +7675,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7712,183 +7714,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7896,17 +7898,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7914,139 +7916,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8056,7 +8058,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8066,69 +8068,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8136,125 +8138,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8262,7 +8264,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8286,7 +8288,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8323,79 +8325,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8403,36 +8405,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11680,10 +11682,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12734,7 +12736,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13379,6 +13381,256 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14280,136 +14532,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14417,113 +14683,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14532,15 +14798,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14548,34 +14814,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14583,15 +14849,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14599,51 +14865,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14651,102 +14917,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14754,44 +15020,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16700,7 +16966,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16725,8 +16991,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16761,7 +17027,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16806,16 +17072,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16911,7 +17177,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17040,7 +17306,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17180,7 +17446,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17195,7 +17461,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17295,44 +17561,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17341,17 +17607,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17363,7 +17629,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17375,25 +17641,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17401,61 +17667,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17466,29 +17732,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17605,9 +17871,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17616,8 +17882,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17856,8 +18122,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18116,7 +18382,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18164,7 +18430,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18302,7 +18568,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18335,10 +18601,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18771,16 +19033,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18823,6 +19085,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19146,8 +19409,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19161,14 +19424,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19200,67 +19463,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19269,334 +19532,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19604,11 +19867,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19617,30 +19880,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19648,11 +19911,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19662,11 +19925,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19675,66 +19938,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19742,38 +20005,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19784,13 +20047,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19833,8 +20096,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19845,7 +20108,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19873,56 +20136,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19930,26 +20193,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -19957,23 +20220,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -19982,129 +20245,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20112,111 +20374,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20246,61 +20508,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20308,7 +20571,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20316,42 +20579,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20359,31 +20622,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20398,186 +20661,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20591,38 +20854,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20631,44 +20894,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20676,27 +20939,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20704,7 +20967,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20712,13 +20975,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20727,113 +20990,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20841,110 +21104,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -20952,12 +21215,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -20970,213 +21233,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21184,38 +21447,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21225,149 +21488,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21375,143 +21638,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21519,78 +21783,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21631,10 +21895,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21686,11 +21950,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21726,7 +21990,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21737,8 +22001,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21753,23 +22017,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21780,7 +22045,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -21994,9 +22259,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22004,46 +22269,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22051,92 +22317,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22158,28 +22423,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22188,7 +22452,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22199,7 +22463,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22209,50 +22473,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22260,137 +22524,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22398,31 +22671,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22436,45 +22709,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22482,68 +22760,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22551,14 +22829,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22571,8 +22849,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22616,7 +22894,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30095,14 +30373,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30122,40 +30400,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30163,37 +30445,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30201,7 +30483,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30211,79 +30493,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30291,7 +30571,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30303,39 +30583,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30344,11 +30624,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30356,51 +30636,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30408,55 +30688,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30465,11 +30745,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30749,10 +31029,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32611,1532 +32887,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40128,7 +38878,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40516,226 +39266,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47181,9 +46050,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47237,7 +46106,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51833,6 +50702,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/nl.po b/weblate/nl.po index e398ae59b0..69f52d4645 100644 --- a/weblate/nl.po +++ b/weblate/nl.po @@ -10,7 +10,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-06 07:06+0000\n" "Last-Translator: jaron maene \n" "Language-Team: Dutch ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3261,109 +3263,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3371,55 +3373,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3427,57 +3429,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3487,17 +3489,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3505,7 +3507,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3513,55 +3515,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3569,24 +3571,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6330,7 +6332,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6353,7 +6355,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6364,8 +6366,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6387,7 +6389,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6451,27 +6453,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6479,17 +6481,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6499,54 +6501,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6555,7 +6557,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6564,18 +6566,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6583,7 +6585,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6591,14 +6593,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6608,60 +6610,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6671,11 +6673,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6683,7 +6685,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6691,15 +6693,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6708,38 +6710,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6748,20 +6750,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6769,15 +6771,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6926,7 +6928,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -6966,7 +6968,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7010,7 +7012,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7034,7 +7036,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7070,7 +7072,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7090,14 +7092,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7107,11 +7109,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7119,7 +7121,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7133,7 +7135,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7148,7 +7150,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7272,7 +7274,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7314,8 +7316,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7349,7 +7351,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7375,19 +7377,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7412,7 +7414,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7435,7 +7437,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7453,7 +7455,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7470,8 +7472,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7506,7 +7508,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7677,7 +7679,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7687,25 +7689,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7726,183 +7728,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7910,17 +7912,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7928,139 +7930,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8070,7 +8072,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8080,69 +8082,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8150,125 +8152,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8276,7 +8278,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8300,7 +8302,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8337,79 +8339,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8417,36 +8419,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11694,10 +11696,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12748,7 +12750,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13393,6 +13395,256 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14294,136 +14546,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14431,113 +14697,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14546,15 +14812,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14562,34 +14828,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14597,15 +14863,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14613,51 +14879,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14665,102 +14931,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14768,44 +15034,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16714,7 +16980,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16739,8 +17005,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16775,7 +17041,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16820,16 +17086,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16925,7 +17191,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17054,7 +17320,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17194,7 +17460,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17209,7 +17475,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17309,44 +17575,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17355,17 +17621,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17377,7 +17643,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17389,25 +17655,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17415,61 +17681,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17480,29 +17746,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17619,9 +17885,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17630,8 +17896,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17870,8 +18136,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18130,7 +18396,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18178,7 +18444,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18316,7 +18582,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18349,10 +18615,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18785,16 +19047,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18837,6 +19099,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19160,8 +19423,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19175,14 +19438,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19214,67 +19477,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19283,334 +19546,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19618,11 +19881,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19631,30 +19894,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19662,11 +19925,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19676,11 +19939,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19689,66 +19952,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19756,38 +20019,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19798,13 +20061,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19847,8 +20110,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19859,7 +20122,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19887,56 +20150,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19944,26 +20207,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -19971,23 +20234,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -19996,129 +20259,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20126,111 +20388,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20260,61 +20522,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20322,7 +20585,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20330,42 +20593,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20373,31 +20636,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20412,186 +20675,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20605,38 +20868,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20645,44 +20908,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20690,27 +20953,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20718,7 +20981,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20726,13 +20989,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20741,113 +21004,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20855,110 +21118,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -20966,12 +21229,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -20984,213 +21247,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21198,38 +21461,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21239,149 +21502,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21389,143 +21652,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21533,78 +21797,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21645,10 +21909,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21700,11 +21964,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21740,7 +22004,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21751,8 +22015,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21767,23 +22031,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21794,7 +22059,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22008,9 +22273,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22018,46 +22283,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22065,92 +22331,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22172,28 +22437,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22202,7 +22466,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22213,7 +22477,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22223,50 +22487,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22274,137 +22538,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22412,31 +22685,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22450,45 +22723,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22496,68 +22774,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22565,14 +22843,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22585,8 +22863,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22630,7 +22908,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30109,14 +30387,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30136,40 +30414,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30177,37 +30459,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30215,7 +30497,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30225,79 +30507,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30305,7 +30585,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30317,39 +30597,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30358,11 +30638,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30370,51 +30650,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30422,55 +30702,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30479,11 +30759,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30763,10 +31043,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32625,1532 +32901,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40142,7 +38892,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40530,226 +39280,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47195,9 +46064,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47251,7 +46120,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51847,6 +50716,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/pl.po b/weblate/pl.po index d610719dbf..e9a658eff3 100644 --- a/weblate/pl.po +++ b/weblate/pl.po @@ -17,7 +17,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-09 13:43+0000\n" "Last-Translator: RM \n" "Language-Team: Polish ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " @@ -4198,23 +4204,23 @@ msgstr "" "wyświetlane przez niego informacje nie były zakryte żadnymi elementami gry, " "takimi jak gracz lub przeciwnik." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "HUD wyświetla następujące informacje:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "Wynik, zmieniany przez ``ScoreTimer``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "Wiadomości takie jak \"Koniec Gry\" lub \"Przygotuj Się!\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "Przycisk \"Start\" rozpoczyna grę." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" @@ -4225,27 +4231,27 @@ msgstr "" "dwóch typów węzła ref:`Control ` - :ref:`Label " "` oraz :ref:`Button `." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "Utwórz je jako dzieci węzła ``HUD``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr ":ref:`Label ` nazwany ``ScoreLabel``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr ":ref:`Label ` nazwany ``MessageLabel``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "Przycisk :ref:` Button ` o nazwie `` StartButton``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr ":ref:`Timer ` o nazwie ``MessageTimer``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -4261,7 +4267,7 @@ msgstr "" "węzła control do jego punktu zakotwiczenia. Więcej informacji na ten temat " "można znaleźć w temacie :ref:`doc_design_interfaces_with_the_control_nodes`." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" @@ -4269,7 +4275,7 @@ msgstr "" "Uporządkuj węzły w sposób pokazany poniżej. Kliknąć przycisk \"Zakotwicz\", " "aby ustawić dla węzła Control kotwicę:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" @@ -4277,97 +4283,97 @@ msgstr "" "Węzły można przeciągnąć ręcznie lub, aby uzyskać bardziej precyzyjne " "rozmieszczenie, należy użyć następujących ustawień:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "ScoreLabel" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "``Layout``: \"Górny Środek\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "``Margines``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "Lewy: ``-25``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "Góra: ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "Prawo: ``25``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "Dół: ``100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "Tekst: ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "MessageLabel" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "``Layout``: \"Środek\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "Lewy: ``-200``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "Góra: ``-150``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "Prawy: ``200``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "Dół: ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "Tekst: ``Dodge the Creeps!``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "StartButton" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "``Layout``: \"Środek Dół\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "Lewy: ``-100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "Góra: ``-200``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "Prawy: ``100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "Dół: ``-100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "Tekst: ``Start``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -4379,13 +4385,13 @@ msgstr "" "Aby użyć tej czcionki, wykonaj następujące czynności dla każdego z trzech " "węzłów ``Control``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" "W zakładce \"Czcionki niestandardowe\" wybierz opcję \"Nowa czcionka " "dynamiczna\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " @@ -4396,18 +4402,18 @@ msgstr "" "Należy również ustawić ``Rozmiar`` czcionki. Ustawienie ``64`` powinno " "działać dobrze." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "Teraz dodaj ten skrypt do ``HUD``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" "Sygnał ``start_game`` informuje węzeł ``Main`` o naciśnięciu przycisku." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " @@ -4417,7 +4423,7 @@ msgstr "" "jak \"Przygotuj się\". W ``MessageTimer`` ustaw ``Czas oczekiwania`` na " "``2`` i ustaw właściwość ``Jednokrotny`` na \"Włączone\"." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." @@ -4426,11 +4432,11 @@ msgstr "" "będzie wyświetlał się napis \"Game Over\" (Koniec Gry), następnie powróci do " "ekranu tytułowego i pojawi się przycisk \"Start\"." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "Funkcja ta jest wywoływana w ``Main`` przy każdej zmianie wyniku." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." @@ -4438,11 +4444,11 @@ msgstr "" "Podłączyć `` Timeout()`` do sygnału ``MessageTimer`` i ``naciśnięty()`` do " "sygnału ``StartButton``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "Podłączenie HUD do Main" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -4454,7 +4460,7 @@ msgstr "" "umieść ją na dole drzewa. Pełne drzewo powinno wyglądać tak, więc upewnij " "się, że niczego nie przegapiłeś:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" @@ -4462,7 +4468,7 @@ msgstr "" "Teraz musimy podłączyć funkcję ``HUD`` do naszego skryptu ``Main``. Wymaga " "to paru poprawek do sceny ``Main``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." @@ -4470,7 +4476,7 @@ msgstr "" "W zakładce Węzeł należy podłączyć sygnał HUD'a ``start_game`` do funkcji " "``new_game()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" @@ -4478,11 +4484,11 @@ msgstr "" "W ``new_game()``, zaktualizuj wyświetlany wynik i pokaż komunikat " "\"Przygotuj się\":" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "W ``game_over() `` musimy wywołać odpowiednią funkcję w ``HUD``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" @@ -4490,7 +4496,7 @@ msgstr "" "Na koniec dodaj to do ``on_on_ScoreTimer_timeout()``, aby wyświetlacz był " "zsynchronizowany ze zmieniającym się wynikiem:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." @@ -4498,11 +4504,11 @@ msgstr "" "Teraz jesteś gotowy do gry! Kliknąć przycisk \"Uruchom projekt\". Zostaniesz " "poproszony o wybranie głównej sceny, więc wybierz ``Main.tscn``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "Kończenie" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " @@ -4513,12 +4519,12 @@ msgstr "" "celu poprawy wrażeń z gry. Zapraszamy do rozszerzenia rozgrywki o własne " "pomysły." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "Tło" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -4534,7 +4540,7 @@ msgstr "" "Wybierz kolor, który chcesz i przeciągnij ``ColorRect`` tak, aby zakrył " "ekran." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." @@ -4542,11 +4548,11 @@ msgstr "" "Obraz tła można również dodać, jeśli taki istnieje, za pomocą węzła " "``Sprite``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "Efekty dźwiękowe" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -4558,7 +4564,7 @@ msgstr "" "\"House In a Forest Loop.ogg\" na muzykę w tle i \"gameover.wav\" odtwarzaną " "w razie przegranej." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -4570,7 +4576,7 @@ msgstr "" "każdym z nich kliknij na właściwość ``Stream``, wybierz opcję \"Wczytaj\" i " "wybierz odpowiedni plik audio." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." @@ -4578,16 +4584,16 @@ msgstr "" "Aby odtwarzać muzykę, dodaj ``$Music.play()`` w funkcji ``new_game()`` i ``" "$Music.stop( ) `` w funkcji `game_over() `." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "Na koniec dodaj ``$DeathSound.play()`` do funkcji ``game_over()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "Cząsteczki" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " @@ -4596,7 +4602,7 @@ msgstr "" "Na koniec dodajmy efekt smugi do ruchu gracza. Wybierz swoją scenę i dodaj " "węzeł :ref:`Particles2D ` o nazwie ``Trail``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " @@ -4606,7 +4612,7 @@ msgstr "" "tworzenia różnych efektów. Aby uzyskać efekt jak w tym przykładzie, należy " "użyć następujących ustawień:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" @@ -4614,14 +4620,14 @@ msgstr "" "Musisz również utworzyć ``Materiał`` klikając na ````, a następnie " "\"New ParticlesMaterial\". Poniżej znajdują się ustawienia w tym zakresie:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" @@ -4629,7 +4635,7 @@ msgstr "" "Kliknij \"New GradientTexture\", a następnie pod \"Gradient\", kliknij " "\"Nowy Gradient\". Zobaczysz takie okno:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -4641,7 +4647,7 @@ msgstr "" "wybrać kolor. Dla pierwszego koloru należy ustawić wartość ``A`` (alfa) na " "około połowę. Dla drugiego, ustaw go aż do ``0``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." @@ -4649,11 +4655,11 @@ msgstr "" "Zobacz :ref:`Particles2D ` aby uzyskać więcej szczegółów " "na temat wykorzystania efektów cząsteczkowych." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "Pliki projektu" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" @@ -4662,7 +4668,7 @@ msgstr "" "kidscancode/Godot3_dodge/releases" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "Eksportowanie" @@ -7601,7 +7607,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -7624,7 +7630,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -7635,8 +7641,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -7658,7 +7664,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -7722,27 +7728,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -7750,17 +7756,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -7770,54 +7776,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -7826,7 +7832,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -7840,18 +7846,18 @@ msgstr "" "``animated_health``. Wywołaj metodę ``interpolate_property`` z węzła " "``Tween``:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "Zerwijmy połączenie:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -7859,7 +7865,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -7867,14 +7873,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -7884,60 +7890,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -7947,11 +7953,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -7959,7 +7965,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -7967,15 +7973,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -7984,38 +7990,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -8024,20 +8030,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -8045,15 +8051,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -8202,7 +8208,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -8242,7 +8248,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -8286,7 +8292,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -8310,7 +8316,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -8346,7 +8352,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -8366,14 +8372,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -8383,11 +8389,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -8395,7 +8401,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -8409,7 +8415,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -8424,7 +8430,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -8548,7 +8554,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -8590,8 +8596,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -8625,7 +8631,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -8651,21 +8657,22 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 +#, fuzzy msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" "Zawiera informacje o grupach i ma możliwość wywołania węzłów w grupie lub " "uzyskania ich listy." #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -8690,7 +8697,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -8713,7 +8720,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -8731,7 +8738,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -8748,8 +8755,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -8784,7 +8791,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -8955,7 +8962,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -8965,25 +8972,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -9009,68 +9016,68 @@ msgstr "" "użytkownika Unit i ma na celu pomóc w migracji istniejącego doświadczenia z " "silnika Unity do świata Godota." -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "Różnice" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "Unity" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "Godot" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Licencja" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" "Własnościowa, zamknięta, darmowa licencja z limitami przychodów i " "ograniczeniami w użytkowaniu" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" "Licencja MIT, wolne i w pełni otwarte oprogramowanie bez żadnych ograniczeń" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "System Operacyjny (edytor)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "Windows, MacOS, Linux (nieoficjalny i niewspierany)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "Windows, macOS, X11 (Linux, \\*BSD)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "System Operacyjny (gra)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "**Desktop:** Windows, macOS, Linux" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "**Mobilne:**Android, iOS, Windows Phone, Tizen" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "**Sieć:** WebAssembly lub asm.js" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "**Konsole:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" @@ -9078,43 +9085,43 @@ msgstr "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "**TV:** Android TV, Samsung SMART TV, tvOS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "**PC:** Windows, macOS, X11" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "**Mobilne:** Android, iOS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "**Web:** WebAssembly" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "**Konsola:** Patrz :ref:`doc_consoles`" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "**VR:** Oculus Rift, SteamVR" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "System scen" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "Komponent/Scena (Obiekt w grze > Komponent)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "Prefaby" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" @@ -9122,55 +9129,55 @@ msgstr "" ":ref:`Drzewo sceny i węzły`, umożliwiające " "zagnieżdżenie scen i/lub dziedziczenie innych scen" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "Obce narzędzia" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "Visual Studio lub VS Code" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr ":ref:`Możliwe są edytory zewnętrzne `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr ":ref:`Android SDK dla eksportu na Android `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "Wybitne elementy w programie" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "Ogromna społeczność" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "Duży sklep zasobów do gry" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "System scen" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr ":ref:`Proste pisanie Shaderów `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "Debugowanie na urządzeniu" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "Edytor" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " @@ -9180,7 +9187,7 @@ msgstr "" "Poniższe ilustracje przedstawiają oba edytory z kolorowymi blokami, aby " "wskazać wspólne funkcjonalności." -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." @@ -9188,13 +9195,14 @@ msgstr "" "Zauważ, że edytor Godot umożliwia zadokowanie każdego panelu, po obu " "stronach edytora sceny." -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#, fuzzy msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" "Oba edytory mogą wydawać się podobne, ale pod maską skrywają wiele różnic. " "Obydwa pozwalają zorganizować projekt przy użyciu systemu plików, ale " @@ -9203,7 +9211,7 @@ msgstr "" "że Godot jest znacznie bardziej przyjazny dla systemów VCS takich jak Git, " "Subversion czy Mercurial." -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -9215,13 +9223,14 @@ msgstr "" "bardziej wizualnie. Innymi słowy, łatwiej jest zrozumieć, co konkretna scena " "robi na pierwszy rzut oka." -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 +#, fuzzy msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" "Inspektor w Godocie jest bardziej minimalistyczny i ma za zadanie jedynie " @@ -9232,7 +9241,7 @@ msgstr "" "tekstur, wyliczeń, a nawet linków do zasobów w czasie rzeczywistym bez " "konieczności stosowania kodu." -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -9240,10 +9249,11 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 +#, fuzzy msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" @@ -9251,70 +9261,77 @@ msgstr "" "sprawdzona(choć może to być wspierane w przyszłości, a wyświetlanie kolizji " "w uruchomionej grze jest już możliwe), ale w zamian ma kilka zalet:" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 +#, fuzzy msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." +"project, close the project, and then reload the previous state)." msgstr "" "Uruchamianie i zamykanie projektu jest szybkie (Unity musi zapisać, " "uruchomić projekt, zamknąć projekt, a następnie załadować poprzedni stan)." -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 +#: ../../docs/getting_started/editor/unity_to_godot.rst:80 +#, fuzzy msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." msgstr "" "Edycja na żywo jest o wiele bardziej przydatna, ponieważ zmiany dokonane w " "edytorze wchodzą w życie natychmiast w grze i nie są tracone (ani nie muszą " "być zsynchronizowane) po zamknięciu gry. Pozwala to na np. tworzenie " "poziomów podczas ich odtwarzania." -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +#, fuzzy +msgid "The editor is more stable because the game runs in a separate process." msgstr "" "Edytor jest bardziej stabilny, ponieważ gra odtwarza się w oddzielnym " "procesie." -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#, fuzzy msgid "" "Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." msgstr "" "Na górnym pasku narzędzi znajduje się również menu do zdalnego debugowania. " "Opcje te ułatwia przesłanie gry na urządzenie (telefon, tablet lub " "przeglądarka poprzez HTML5) i edycję debugowania/edycji na żywo po " "wyeksportowaniu gry." -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 msgid "The scene system" msgstr "System sceny" -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#, fuzzy msgid "" -"This is the most important difference between Unity and Godot, and actually " +"This is the most important difference between Unity and Godot and, actually, " "the favourite feature of most Godot users." msgstr "" "Jest to najważniejsza różnica pomiędzy Unity i Godotem, a ulubioną cechą " "większości użytkowników Godot." -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#, fuzzy msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." msgstr "" "System sceny Unity polega na osadzeniu wszystkich wymaganych zasobów w " "scenie i połączeniu ich poprzez ustawienie komponentów i skryptów." -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +#, fuzzy msgid "" "Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." msgstr "" "System scen Godota jest inny: w rzeczywistości składa się z drzewa " "zbudowanego z węzłów. Każdy węzeł spełnia swoją rolę: Sprite, Mesh, Light... " @@ -9323,7 +9340,7 @@ msgstr "" "podsceną sceny głównej. Oznacza to, że można utworzyć całą scenę z różnymi " "scenami, przechowywaną w różnych plikach." -#: ../../docs/getting_started/editor/unity_to_godot.rst:80 +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" @@ -9331,29 +9348,30 @@ msgstr "" "Na przykład, pomyśl o poziomie z gry platformowej. Można go skomponować z " "wielu elementów:" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "Cegły" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "Monety" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "Gracz" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "Wrogowie" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#, fuzzy msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" "W Unity, można umieścić wszystkie obiekty gry(GameObjects) na scenie: gracz, " @@ -9362,7 +9380,7 @@ msgstr "" "aby je połączyć: na przykład do wszystkich elementów sceny można dodać " "BoxCollider2D, aby mogły się zderzać. Zasada ta jest odmienna u Godota." -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." @@ -9370,11 +9388,11 @@ msgstr "" "W Godot podzieliłbyś całą scenę na 3 mniejsze, oddzielne sceny, które można " "by potem były instancjowane w głównej scenie." -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "** Po pierwsze, scena dla gracza.**" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " @@ -9385,11 +9403,11 @@ msgstr "" "zawiera teksturę sprite, tworzącą różne animacje (na przykład animację " "chodzenia)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "**Po drugie, scena dla wrogów.**" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " @@ -9400,18 +9418,19 @@ msgstr "" "zarządza głównie sztuczną inteligencją) i sprity używane przez " "AnimatedSprite." -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "**Na koniec, scena poziomu**" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#, fuzzy msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" "Składa się z Cegieł (platformy), Monet (zbieranych przez gracza) i pewnej " "liczby instancji sceny wroga. Będą to wrogowie, których zachowanie i wygląd " @@ -9419,7 +9438,7 @@ msgstr "" "traktowana jako węzeł w drzewie sceny Level. Oczywiście możesz ustawić różne " "właściwości dla każdego węzła wroga (na przykład zmienić jego kolor)." -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -9429,7 +9448,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -9439,69 +9458,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -9509,118 +9528,119 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 +#, fuzzy msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" "Ale to nie wszystko! Niektóre węzły wysyłają sygnały, gdy pewne działania " "mają miejsce. Sygnały te można podłączyć w celu wywołania określonej " @@ -9628,11 +9648,11 @@ msgstr "" "dowolnym czasie. Ta cecha jest udokumentowana `tutaj <../scripting/gdscript/" "gdscript_basics.html#signals>`_." -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "Używanie C++ w Godot" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -9644,7 +9664,7 @@ msgstr "" "przykład, można rozważyć edytor Godot Engine jako \"grę\" napisaną w C++ za " "pomocą Godot API." -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -9671,7 +9691,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -9708,79 +9728,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -9788,36 +9808,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -13075,10 +13095,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -14129,7 +14149,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -14774,6 +14794,259 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +#, fuzzy +msgid "Export of Blender materials" +msgstr "Szablony do eksportu" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Nie ma żadnych ograniczeń w stosowaniu Godota" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +#, fuzzy +msgid "There are the following caveats:" +msgstr "Scena Mob będzie korzystać z następujących węzłów:" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -15736,136 +16009,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -15873,113 +16160,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -15988,15 +16275,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -16004,34 +16291,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -16039,15 +16326,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -16055,51 +16342,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -16107,102 +16394,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -16210,44 +16497,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -18173,7 +18460,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -18198,8 +18485,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -18234,7 +18521,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -18279,16 +18566,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -18384,7 +18671,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -18513,7 +18800,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -18653,7 +18940,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -18668,7 +18955,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -18768,44 +19055,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -18814,17 +19101,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -18836,7 +19123,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -18848,25 +19135,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -18874,61 +19161,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -18939,29 +19226,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -19078,9 +19365,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -19089,8 +19376,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -19342,9 +19629,10 @@ msgid "Hue variation" msgstr "Zróżnicowanie odcieni barw" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 +#, fuzzy msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" "Wartość zmiany określa początkową zmianę barwy zastosowaną do każdej " "cząsteczki. Wartość Variation rand kontroluje losowość zmienności barwy." @@ -19611,7 +19899,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -19659,7 +19947,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -19797,7 +20085,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -19830,10 +20118,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -20266,16 +20550,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -20318,6 +20602,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -20641,8 +20926,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -20656,14 +20941,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -20695,67 +20980,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -20764,334 +21049,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -21099,11 +21384,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -21112,30 +21397,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -21143,11 +21428,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -21157,11 +21442,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -21170,66 +21455,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -21237,38 +21522,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -21279,13 +21564,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -21328,8 +21613,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -21340,7 +21625,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -21368,56 +21653,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -21425,26 +21710,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -21452,23 +21737,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -21477,129 +21762,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -21607,111 +21891,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -21741,61 +22025,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -21803,7 +22088,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -21811,42 +22096,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -21854,31 +22139,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -21893,186 +22178,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -22086,38 +22371,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -22126,44 +22411,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -22171,27 +22456,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -22199,7 +22484,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -22207,13 +22492,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -22222,113 +22507,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -22336,110 +22621,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -22447,12 +22732,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -22465,213 +22750,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -22679,38 +22964,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -22720,149 +23005,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -22870,108 +23155,108 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" @@ -22979,36 +23264,37 @@ msgstr "" "Domyślnie, nawet jeśli efekt jest włączony, będzie słaby lub niewidoczny. " "Jeden z dwóch warunków musi się spełnić, by się pojawił:" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -23016,78 +23302,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -23128,10 +23414,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -23183,11 +23469,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -23223,7 +23509,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -23234,8 +23520,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -23250,23 +23536,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -23277,7 +23564,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -23517,9 +23804,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -23527,46 +23814,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -23574,92 +23862,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "Siatka, którą chcesz powielić na powierzchni docelowej." -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "Losowy obrót" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "Losowa skala" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -23681,28 +23968,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -23711,7 +23997,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -23722,7 +24008,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -23732,50 +24018,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -23783,137 +24069,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -23921,31 +24216,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -23959,45 +24254,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -24005,68 +24305,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -24074,14 +24374,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -24094,8 +24394,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -24139,7 +24439,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -31673,14 +31973,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -31700,40 +32000,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -31741,37 +32045,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -31779,7 +32083,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -31789,79 +32093,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -31869,7 +32171,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -31881,39 +32183,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -31922,11 +32224,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -31934,51 +32236,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -31986,55 +32288,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -32043,11 +32345,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -32327,10 +32629,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -34189,1532 +34487,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -41761,7 +40533,7 @@ msgid "Or alternatively, set it via function:" msgstr "Lub alternatywnie, ustaw to za pomocą funkcji:" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -42149,226 +40921,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -48819,9 +47710,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -48875,7 +47766,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -53472,6 +52363,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/pt_BR.po b/weblate/pt_BR.po index 7852f40a38..87a07cf587 100644 --- a/weblate/pt_BR.po +++ b/weblate/pt_BR.po @@ -37,7 +37,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-16 00:43+0000\n" "Last-Translator: Julio Yagami \n" "Language-Team: Portuguese (Brazil) ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " @@ -4327,23 +4334,23 @@ msgstr "" "informações que ela mostrar não fiquem cobertas por quaisquer elementos do " "jogo, como o jogador ou os inimigos." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "O HUD exibirá as seguintes informações:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "Pontuação, alterado por ``ScoreTimer``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "Uma mensagem, como \"Game Over\" ou \"Prepare-se!\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "Um botão \"Iniciar\" para começar o jogo." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" @@ -4353,27 +4360,27 @@ msgstr "" "Para criar nossa interface, usaremos dois tipos de nós :ref:`Control " "`: :ref:`Label ` e :ref:`Button `." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "Crie os seguintes itens como filhos do nó ``HUD``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr ":ref:`Label ` nomeado ``ScoreLabel``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr ":ref:`Label ` nomeado ``MessageLabel``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr ":ref:`Button ` nomeado ``StartButton``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr ":ref:`Timer ` nomeado ``MessageTimer``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -4389,7 +4396,7 @@ msgstr "" "das bordas do nó Control até sua âncora. Veja :ref:" "`doc_design_interfaces_with_the_control_nodes` para mais detalhes." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" @@ -4397,7 +4404,7 @@ msgstr "" "Organize os nós conforme mostrado abaixo. Clique no botão \"Âncora\" para " "definir a âncora para um nó Control:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" @@ -4405,97 +4412,97 @@ msgstr "" "Você pode arrastar os nós para colocá-los manualmente ou, para um " "posicionamento mais preciso, usar as seguintes configurações:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "ScoreLabel" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "``Layout``: \"Center Top\" (Centro Superior)" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "``Margin``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "Left: ``-25``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "Top: ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "Right: ``25``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "Bottom: ``100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "Text: ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "MessageLabel" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "``Layout``: \"Center\" (Centro)" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "Left: ``-100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "Top: ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "Right: ``100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "Bottom: ``100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "Texto: ``Desvie dos Bichos!``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "StartButton" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "``Layout``: \"Center Bottom\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "Left: ``-100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "Top: ``-200``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "Right: ``100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "Bottom: ``-100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "Texto: ``Iniciar``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -4507,13 +4514,13 @@ msgstr "" "\". Para usar esta fonte, faça o seguinte para cada um dos três nós " "``Control``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" "Na propriedade \"Custom Fonts\" (Fontes Personalizadas), escolha \"Novo " "DynamicFont\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " @@ -4524,17 +4531,17 @@ msgstr "" "Você tem também que definir o tamanho (``Size``) da fonte. Uma configuração " "de ``64`` funciona bem." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "Agora, adicione este script ao ``HUD``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "O sinal ``start_game`` diz ao nó ``Main`` que o botão foi pressionado." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " @@ -4545,7 +4552,7 @@ msgstr "" "Espera) para ``2`` e configure a propriedade ``One Shot`` (Apenas uma Vez) " "como \"Ativo\"." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." @@ -4553,11 +4560,11 @@ msgstr "" "Esta função é chamada quando o jogador perde. Ela mostrará \"Game Over\" por " "2 segundos, depois retornará à tela de título e mostrará o botão \"Iniciar\"." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "Esta função é chamada em ``Main``sempre que a pontuação for alterada." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." @@ -4565,11 +4572,11 @@ msgstr "" "Conecte o sinal ``timeout()`` (\"tempo esgotado\") de ``MessageTimer`` e o " "sinal ``pressed()`` (\"pressionado\") de ``StartButton``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "Conectando HUD a Principal" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -4581,7 +4588,7 @@ msgstr "" "``Jogador``, e coloque-a no final da árvore. A árvore completa deveria se " "parecer assim, então confira que não falta alguma coisa:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" @@ -4589,14 +4596,14 @@ msgstr "" "Agora precisamos conectar a funcionalidade de ``HUD`` ao roteiro de " "``Principal``. Isso exige algumas adições à cena ``Principal``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" "Na aba Nó, conecte o sinal ``start_game`` de HUD à função ``new_game()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" @@ -4604,12 +4611,12 @@ msgstr "" "Em ``new_game()``, atualize o mostrador de pontuação e mostre a mensagem " "\"Prepare-se\":" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" "Em ``game_over()``, precisamos chamar a correspondente função de ``HUD``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" @@ -4617,7 +4624,7 @@ msgstr "" "Finalmente, adicione isto a ``_on_ScoreTimer_timeout()`` para manter o " "mostrador em sincronia com as mudanças de pontuação:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." @@ -4625,11 +4632,11 @@ msgstr "" "Agora está tudo pronto para jogar! Clique no botão \"Rodar o Projeto\". Será " "solicitada a seleção de uma cena principal, então escolha ``Principal.tscn``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "Finalizando" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " @@ -4640,12 +4647,12 @@ msgstr "" "experiência do jogo. Sinta-se livre para expandir a jogabilidade com suas " "próprias ideias." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "Plano de fundo" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -4662,7 +4669,7 @@ msgstr "" "cor que goste e, com o mouse, altere as dimensões do ``ColorRect`` para que " "cubra a tela." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." @@ -4670,11 +4677,11 @@ msgstr "" "Você também pode adicionar uma imagem de plano de fundo, se tiver uma, " "usando um nó ``Sprite``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "Efeitos Sonoros" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -4686,7 +4693,7 @@ msgstr "" "de áudio: \"House In a Forest Loop.ogg\" para música de fundo e \"gameover." "wav\" para quando o jogador perde." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -4698,7 +4705,7 @@ msgstr "" "``SomDeMorte``. Em cada um, clique na propriedade ``Stream`` (\"fluxo\"), " "selecione \"Carregar\", e escolha o arquivo sonoro correspondente." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." @@ -4706,16 +4713,16 @@ msgstr "" "Para reproduzir a música, adicione ``$Musica.play()``na função " "``new_game()`` e ``$Musica.stop()`` na função ``game_over()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "Por fim, adicione ``$SomDeMorte.play()`` na função ``game_over()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "Partículas" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " @@ -4725,7 +4732,7 @@ msgstr "" "ao movimento do jogador. Escolha a sua cena ``Jogador`` e adicione um nó :" "ref:`Particles2D ` chamado ``Rastro``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " @@ -4735,7 +4742,7 @@ msgstr "" "de partículas. Sinta-se à vontade para experimentar e criar diferentes " "efeitos. Para o efeito neste exemplo, use as seguintes configurações:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" @@ -4743,7 +4750,7 @@ msgstr "" "Você também precisa criar um ``Material` clicando no ```` e então em " "\"Novo ParticlesMaterial\". As configurações para isso estão a seguir:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " @@ -4753,7 +4760,7 @@ msgstr "" "nós queremos uma graduação do parâmetro alfa (transparência) do *sprite* de " "0,5 (semitransparente) até 0,0 (completamente transparente)." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" @@ -4761,7 +4768,7 @@ msgstr "" "Clique em \"Novo GradientTexture\"; depois, em \"Gradient\", clique em " "\"Novo Gradient\". Você verá uma janela como esta:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -4773,7 +4780,7 @@ msgstr "" "a cor. Para a primeira cor, defina o valor ``A`` (alfa) para mais ou menos a " "metade. Já para a segunda, configure para ``0``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." @@ -4781,11 +4788,11 @@ msgstr "" "Veja :ref:`Particles2D ` para maiores detalhes sobre uso " "dos efeitos das partículas." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "Arquivos do Projeto" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" @@ -4794,7 +4801,7 @@ msgstr "" "com/kidscancode/Godot3_dodge/releases" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "Exportando" @@ -8688,7 +8695,8 @@ msgstr "" "selecionou." #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +#, fuzzy +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" "A primeira seção lista os sinais personalizados definidos em `` player.GD``:" @@ -8709,12 +8717,13 @@ msgid "We're connecting to the health\\_changed signal" msgstr "Estamos nos conectando ao sinal health\\_changed" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:234 +#, fuzzy msgid "" "Select ``health_changed`` and click on the Connect button in the bottom " "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -8731,9 +8740,10 @@ msgid "The Connect Signal window with the GUI node selected" msgstr "A janela Conectar Sinal com o nó GUI selecionado" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 +#, fuzzy msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" "Você pode, opcionalmente, conectar nós do código. Mas fazê-lo do editor tem " "duas vantagens:" @@ -8752,6 +8762,7 @@ msgstr "" "Um ícone de emissor aparece ao lado do nó que emite o sinal na doca Scene" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:253 +#, fuzzy msgid "" "At the bottom of the window you will find the path to the node you selected. " "We're interested in the second row called \"Method in Node\". This is the " @@ -8760,7 +8771,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" "Na parte inferior da janela, você encontrará o caminho para o nó " "selecionado. Estamos interessados na segunda linha chamada \"Método no Nó\". " @@ -8854,22 +8865,22 @@ msgstr "" "Crie um novo método `` update_health`` abaixo de `` " "_on_Player_health_changed``. Leva um novo valor como seu único argumento:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "Este método precisa:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" "setar o `` text`` do nó `` Number`` para `` new_value`` convertido para uma " "string" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "setar `` value`` do `` TextureProgress`` para `` new_value``" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " @@ -8879,7 +8890,7 @@ msgstr "" "propriedade `` text`` do `` Number`` requer uma string, então não podemos " "atribuí-la ao `` new_value`` diretamente" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -8891,18 +8902,18 @@ msgstr "" "jogo. Pressione F5 para testar o jogo: a barra de vida é atualizada a cada " "ataque!" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" "O nó Number e o TextureProgress são atualizados quando o Player recebe um hit" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "Animar a perda de vida com o nó Tween" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -8918,7 +8929,7 @@ msgstr "" "no `` TextureProgress`` do seu nível atual para o novo `` health`` do `` " "Player`` quando o personagem recebe dano." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " @@ -8928,7 +8939,7 @@ msgstr "" "tween``. Vamos agora usá-lo. Nós temos que fazer algumas mudanças em `` " "update_health``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" @@ -8936,35 +8947,35 @@ msgstr "" "Nós usaremos o método `` interpolate_property`` do nó `` Tween``. São " "necessários sete argumentos:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "Uma referência ao nó que possui a propriedade para animar" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "O identificador da propriedade como uma string" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "O valor inicial" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "O valor final" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "A duração da animação em segundos" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "O tipo da transição" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "O alívio para usar em combinação com a equação." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." @@ -8973,7 +8984,7 @@ msgstr "" "atenuação <#> `__. Isso controla como o valor evolui do início ao ponto " "final." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -8987,7 +8998,7 @@ msgstr "" "um número, mas não para animar o texto diretamente. Vamos usá-lo para animar " "uma nova variável `` GUI`` chamada `` animated_health``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -9000,11 +9011,11 @@ msgstr "" "`` update_health`` e limpe seu conteúdo. Vamos animar o valor `` " "animated_health``. Chame o método `` interpolate_property`` do nó `` Tween``:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "Vamos dividir a ligação:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " @@ -9014,7 +9025,7 @@ msgstr "" "interpolação de `` Tween`` \\ _property toma o nome da propriedade como uma " "string. É por isso que nós escrevemos como `` \"animated_health\" ``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -9026,7 +9037,7 @@ msgstr "" "animação é `` health`` do `` Player`` depois do `` health_changed``: é `` " "new_value``. E `` 0.6`` é a duração da animação em segundos." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -9038,7 +9049,7 @@ msgstr "" "faz nada com uma transição linear, mas devemos fornecer este último " "argumento ou obteremos um erro." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " @@ -9048,7 +9059,7 @@ msgstr "" "tween.start () ``. Nós só temos que fazer isso uma vez se o nó não estiver " "ativo. Adicione este código após a última linha:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -9064,11 +9075,11 @@ msgstr "" "separado. O nó `tween` é perfeito para animações controladas por código. " "Para animações feitas à mão, confira `AnimationPlayer`." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "Atribuir a \\ _health animada para o LifeBar" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." @@ -9076,11 +9087,11 @@ msgstr "" "Agora a variável `` animated_health`` anima, mas nós não atualizamos mais os " "nós `` Bar`` e `` Number``. Vamos consertar isso." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "Até agora, o método update \\ _health se parece com isto:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " @@ -9090,7 +9101,7 @@ msgstr "" "usar o método `` _process`` para animá-lo. Vamos agora atualizar os nós `` " "Number`` e `` TextureProgress`` como antes, dentro de `` _process``:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." @@ -9098,7 +9109,7 @@ msgstr "" "`number_label` e` bar` são variáveis que armazenam referências aos nós " "`Number` e` TextureProgress`." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " @@ -9108,11 +9119,11 @@ msgstr "" "decimal e parece uma bagunça. E considerando o estilo do jogo, seria bom " "para a barra de vida para animar de uma forma mais bonita." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "A animação é suave, mas o número está quebrado" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " @@ -9123,16 +9134,16 @@ msgstr "" "animated_health`` arredondado. Em seguida, atribua-o a `` number_label." "text`` e `` bar.value``:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "Rode o jogo novamente para ver uma bela animação em blocos." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" "Ao arredondar animated\\_health, acertamos dois coelhos com uma só cajadada" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 #, fuzzy msgid "" "Every time the player takes a hit, the ``GUI`` calls " @@ -9149,11 +9160,11 @@ msgstr "" "gradualmente é um truque. Faz a GUI parecer viva. Se o `` Player`` receber 3 " "de dano, isso acontece em um instante." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "Clareia a barra quando o jogador morre" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 #, fuzzy msgid "" "When the green character dies, it plays a death animation and fades out. At " @@ -9166,7 +9177,7 @@ msgstr "" "desaparecer também quando o personagem morrer. Vamos reutilizar o mesmo nó " "`` Tween`` enquanto ele gerencia múltiplas animações em paralelo para nós." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 #, fuzzy msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " @@ -9179,15 +9190,15 @@ msgstr "" "trabalho 2D. Selecione o nó `` Player`` na doca Scene e clique na aba Node " "ao lado do Inspector." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "Encontre o sinal `` morreu``, selecione-o e clique no botão Conectar." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "O sinal já deve ter o inimigo conectado a ele" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -9201,11 +9212,11 @@ msgstr "" "na parte inferior da janela. Isso levará você ao arquivo `` GUI.gd`` no " "espaço de trabalho do Script." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "Você deve obter esses valores na janela Conectando um sinal" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " @@ -9215,7 +9226,7 @@ msgstr "" "informação, emitimos um novo sinal. Use-os com sabedoria: quanto mais " "conexões você adicionar, mais difícil será rastrear." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." @@ -9224,7 +9235,7 @@ msgstr "" "sua propriedade `` modulate``. `` modulate`` é uma `` Cor`` que multiplica " "as cores de nossas texturas." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " @@ -9234,7 +9245,7 @@ msgstr "" "Ele permite que você alterne a visibilidade do nó, atribua um sombreador a " "ele e modifique-o usando uma cor com `modulate`." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " @@ -9244,7 +9255,7 @@ msgstr "" "e alfa. Se escurecermos qualquer um dos três primeiros canais, escurecerá a " "interface. Se abaixarmos o canal alfa, nossa interface desaparece." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -9258,7 +9269,7 @@ msgstr "" "método `` _on_Player_died`` e nomea-las `` start_color`` e `` end_color``. " "Use o construtor `` Color () `` para construir dois valores `` Color``." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " @@ -9268,7 +9279,7 @@ msgstr "" "respectivamente `` 1.0`` e `` 0.0`` em `` start_color`` e `` end_color``, é " "o canal alfa." -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" @@ -9276,7 +9287,7 @@ msgstr "" "Nós então temos que chamar o método `` interpolate_property`` do nó `` " "Tween`` novamente:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -9288,15 +9299,15 @@ msgstr "" "transição linear. Aqui, novamente, porque a transição é linear, o alívio não " "importa. Aqui está o método `` _on_Player_died`` completo:" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "E é isso. Agora você pode jogar o jogo para ver o resultado final!" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "O resultado, final Parabéns por chegar lá!" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -9490,7 +9501,8 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "O quadro-chave será adicionado ao editor do player de animação:" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +#, fuzzy +msgid "Move the editor cursor to the end by clicking here:" msgstr "Mova o cursor do editor para o final, clicando aqui:" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -9534,9 +9546,10 @@ msgid "Nodes and resources" msgstr "Nós e recursos" #: ../../docs/getting_started/step_by_step/resources.rst:9 +#, fuzzy msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -9599,9 +9612,10 @@ msgstr "" "dados, portanto, não é necessário duplicá-los." #: ../../docs/getting_started/step_by_step/resources.rst:42 +#, fuzzy msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -9633,8 +9647,9 @@ msgstr "" "nó: ref: `Sprite `:" #: ../../docs/getting_started/step_by_step/resources.rst:61 +#, fuzzy msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -9683,9 +9698,10 @@ msgstr "" "primeiro é usar o load(), assim:" #: ../../docs/getting_started/step_by_step/resources.rst:101 +#, fuzzy msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" "A segunda maneira é mais ideal, mas só funciona com um parâmetro de " "constante de string, porque ele carrega o recurso em tempo de compilação." @@ -9712,7 +9728,7 @@ msgstr "" "Para obter uma instância da cena, o método: ref: `PackedScene.instance () " "` deve ser usado." -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " @@ -9722,7 +9738,7 @@ msgstr "" "propriedades) e retorna o nó raiz da cena, que pode ser adicionado a " "qualquer outro nó." -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -9739,11 +9755,11 @@ msgstr "" "que, como sempre, imagens, malhas, etc são todos compartilhados entre as " "instâncias da cena." -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "Liberando recursos" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -9756,7 +9772,7 @@ msgstr "" "recursos, quando um nó é removido ou liberado, todos os recursos filhos são " "liberados também." -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -9771,9 +9787,10 @@ msgid "File system" msgstr "Sistema de arquivo" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 +#, fuzzy msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -9799,7 +9816,7 @@ msgstr "" "arquivos." #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "Implementação" @@ -9967,11 +9984,12 @@ msgstr "" "para o novo local do ativo." #: ../../docs/getting_started/step_by_step/filesystem.rst:103 +#, fuzzy msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" "Para evitar isso, faça todas as suas movimentações, exclua e renomeie as " "operações de dentro da Godot, na estação FileSystem. Nunca mova ativos de " @@ -10031,10 +10049,11 @@ msgstr "" "árvore de cena *." #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 +#, fuzzy msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" "Este conceito merece entrar em mais detalhes. Na verdade, o sistema de cena " @@ -10086,8 +10105,9 @@ msgstr "" "próprio MainLoop raramente faz sentido." #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 +#, fuzzy msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" "Uma das maneiras de explicar como Godot funciona é que é um mecanismo de " @@ -10120,9 +10140,10 @@ msgstr "" "É importante saber que essa classe existe porque tem alguns usos importantes:" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 +#, fuzzy msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" "Ele contém a raiz: ref: `Viewport `, para a qual uma cena é " @@ -10130,16 +10151,18 @@ msgstr "" "tornar parte da * Scene Tree * (mais sobre isso a seguir)" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 +#, fuzzy msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" "Ele contém informações sobre os grupos e tem meios para chamar todos os nós " "de um grupo ou obter uma lista deles." #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 +#, fuzzy msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" "Ela contém alguma funcionalidade de estado global, como configurar o modo de " @@ -10168,10 +10191,11 @@ msgstr "" "nó, ele pode ser obtido de duas maneiras diferentes:" #: ../../docs/getting_started/step_by_step/scene_tree.rst:88 +#, fuzzy msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" "Este nó contém o viewport principal, qualquer coisa que é filho de: ref: " @@ -10202,8 +10226,9 @@ msgstr "" "torna parte da * árvore de cena *." #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 +#, fuzzy msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" "Isso significa que, como explicado nos tutoriais anteriores, ele obterá os " @@ -10228,7 +10253,7 @@ msgstr "Ordem da árvore" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 #, fuzzy msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -10247,10 +10272,11 @@ msgid "A scene is loaded from disk or created by scripting." msgstr "Uma cena é carregada do disco ou criada pelo script." #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 +#, fuzzy msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" "O nó raiz dessa cena (apenas uma raiz, lembra?) É adicionado como um filho " "da viewport \"root\" (de SceneTree), ou para qualquer filho ou neto dela." @@ -10297,8 +10323,9 @@ msgstr "" "change_scene () `:" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 +#, fuzzy msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -10533,7 +10560,7 @@ msgstr "" "Em seguida vem a função para trocar de cena. Esta função libera a cena atual " "e a substitui pela cena requisitada." -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -10549,7 +10576,7 @@ msgstr "" "função acontecerá num momento posterior em que nenhum código da cena atual " "esteja rodando." -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" @@ -10557,20 +10584,20 @@ msgstr "" "Finalmente, tudo que resta é completar as funções vazias em scene_a.gd e " "scene_b.gd:" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "e" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" "Agora se você roda o projeto, você pode trocar de cena pressionando o botão!" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -10596,67 +10623,67 @@ msgstr "" "usuário Unity, e procura te ajudar a migrar sua experiência em Unity para o " "mundo do Godot." -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "Diferenças" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "Unity" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "Godot" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Licença" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" "Proprietário, código fechado, licença grátis com teto de rendimento e " "restrições de uso" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "Licença MIT, grátis e código totalmente aberto sem nenhuma restrição" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "OS (editor)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "Windows, macOS, Linux (não oficial e sem suporte)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "Windows, macOS, X11 (Linux, \\*BSD)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "OS (exportar)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "**Desktop:** Windows, macOS, Linux" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "**Dispositivos móveis:** Android, iOS, Windows Phone, Tizen" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "**Web:** WebAssembly ou asm.js" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" @@ -10664,43 +10691,43 @@ msgstr "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "**TV:** Android TV, Samsung Smart TV, tvOS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "**Desktop:** Windows, macOS, X11" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "**Dispositivos móveis:** Android, iOS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "**Web:** WebAssembly" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "**Console:** Ver :ref:`doc_consoles`" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "**VR:** Oculus Rift, SteamVR" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "Sistema de cenas" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "Componente/Cena (GameObject > Component)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "Prefabs" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" @@ -10708,56 +10735,56 @@ msgstr "" ":ref:`Árvore de cenas e nós `, permitindo que cenas " "sejam aninhadas e/ou herdem outras cenas" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "Ferramentas de terceiros" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "Visual Studio ou VS Code" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr ":ref:`Editores externos são possíveis `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" ":ref:`Android SDK para exportação a Android `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "Recursos decisivos" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "Comunidade enorme" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "Grande armazém de recursos" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "Sistema de cenas" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr ":ref:`Canalização de Animações `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr ":ref:`Facilidade para escrever Shaders `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "Depuração no dispositivo" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "O editor" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " @@ -10767,7 +10794,7 @@ msgstr "" "seus jogos. As imagens abaixo exibem os dois editores com blocos coloridos " "para indicar funcionalidades comuns." -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." @@ -10775,16 +10802,16 @@ msgstr "" "Note que o editor Godot permite você encaixar cada painel ao lado do editor " "de cena da maneira que preferir." -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -10792,17 +10819,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -10810,139 +10837,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -10952,7 +10979,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -10962,69 +10989,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -11032,125 +11059,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -11158,7 +11185,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -11182,7 +11209,7 @@ msgstr "Caminho" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -11219,79 +11246,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -11299,36 +11326,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -15241,12 +15268,13 @@ msgstr "" "propiedades:" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 +#, fuzzy msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" "Como pode ser visto acima, o tipo e o valor inicial da variável podem ser " "alterados, assim como alguns sinais de propriedade (@TODO, documentar isso). " @@ -16492,7 +16520,7 @@ msgstr "get_scale()" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "Scale" @@ -17239,6 +17267,261 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +#, fuzzy +msgid "Export of Blender materials" +msgstr "Modelos de Exportação" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Não há restrições para usar Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +#, fuzzy +msgid "Physics Properties" +msgstr "Propriedades do Node" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "Tipo" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +#, fuzzy +msgid "There are the following caveats:" +msgstr "A cena Turba utilizará os seguintes nós:" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -18143,136 +18426,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "Crie um script que pareça isto:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -18280,113 +18577,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -18395,15 +18692,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -18411,34 +18708,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -18446,15 +18743,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "FPS" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -18462,51 +18759,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -18514,102 +18811,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -18617,44 +18914,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -20564,7 +20861,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -20589,8 +20886,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -20625,7 +20922,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -20670,16 +20967,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -20775,7 +21072,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -20904,7 +21201,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -21044,7 +21341,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -21059,7 +21356,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -21159,44 +21456,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -21205,17 +21502,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -21227,7 +21524,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -21239,25 +21536,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -21265,61 +21562,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -21330,29 +21627,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Ferramentas" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -21469,9 +21766,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -21480,8 +21777,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -21720,8 +22017,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -21980,7 +22277,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -22028,7 +22325,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -22166,7 +22463,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -22199,10 +22496,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -22635,16 +22928,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -22687,6 +22980,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -23010,8 +23304,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -23025,14 +23319,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -23064,67 +23358,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -23133,334 +23427,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -23468,11 +23762,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -23481,30 +23775,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -23512,11 +23806,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -23526,11 +23820,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Profundidade" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -23539,66 +23833,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -23606,38 +23900,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -23648,13 +23942,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -23697,8 +23991,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -23709,7 +24003,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -23741,56 +24035,56 @@ msgstr "" "custo de desempenho. Existe uma lista de parâmetros de sombra genéricos, " "cada um também tem uma função específica:" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -23798,26 +24092,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -23825,23 +24119,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -23850,129 +24144,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -23980,111 +24273,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -24114,61 +24407,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -24176,7 +24470,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -24184,42 +24478,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -24227,31 +24521,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -24266,186 +24560,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -24459,38 +24753,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -24499,44 +24793,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -24544,27 +24838,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -24572,7 +24866,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -24580,13 +24874,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -24595,113 +24889,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -24709,110 +25003,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -24820,12 +25114,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -24838,213 +25132,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -25052,38 +25346,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -25093,149 +25387,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -25243,143 +25537,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -25387,78 +25682,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -25499,10 +25794,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -25554,11 +25849,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -25594,7 +25889,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -25605,8 +25900,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -25621,23 +25916,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -25648,7 +25944,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -25862,9 +26158,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -25872,46 +26168,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -25919,92 +26216,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -26026,28 +26322,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -26056,7 +26351,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -26067,7 +26362,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -26077,50 +26372,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -26128,137 +26423,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -26266,31 +26570,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -26304,45 +26608,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -26350,68 +26659,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -26419,14 +26728,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -26439,8 +26748,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -26484,7 +26793,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -34067,14 +34376,14 @@ msgid "Audio" msgstr "Áudio" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -34094,40 +34403,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -34135,37 +34448,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -34173,7 +34486,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -34183,79 +34496,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -34263,7 +34574,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -34275,39 +34586,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -34316,11 +34627,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -34328,51 +34639,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -34380,55 +34691,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -34437,11 +34748,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -34721,10 +35032,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -36599,1532 +36906,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -44125,7 +42906,7 @@ msgid "Or alternatively, set it via function:" msgstr "Ou de modo alternativo, preencha através de função:" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -44513,226 +43294,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -51183,9 +50083,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -51239,7 +50139,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -55835,6 +54735,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/pt_PT.po b/weblate/pt_PT.po index 1dd24008ed..b01f4cf20c 100644 --- a/weblate/pt_PT.po +++ b/weblate/pt_PT.po @@ -11,7 +11,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-12 10:42+0000\n" "Last-Translator: Alexandre Badalo \n" "Language-Team: Portuguese (Portugal) ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3321,109 +3323,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3431,55 +3433,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3487,57 +3489,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3547,17 +3549,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3565,7 +3567,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3573,55 +3575,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "Partículas" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3629,24 +3631,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6391,7 +6393,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6414,7 +6416,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6425,8 +6427,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6448,7 +6450,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6512,27 +6514,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6540,17 +6542,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6560,54 +6562,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6616,7 +6618,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6625,18 +6627,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6644,7 +6646,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6652,14 +6654,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6669,60 +6671,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6732,11 +6734,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6744,7 +6746,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6752,15 +6754,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6769,38 +6771,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6809,20 +6811,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6830,15 +6832,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6987,7 +6989,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7027,7 +7029,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7071,7 +7073,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7095,7 +7097,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7131,7 +7133,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7151,14 +7153,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7168,11 +7170,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7180,7 +7182,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7194,7 +7196,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7209,7 +7211,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7333,7 +7335,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7375,8 +7377,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7410,7 +7412,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7436,19 +7438,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7473,7 +7475,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7496,7 +7498,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7514,7 +7516,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7531,8 +7533,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7567,7 +7569,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7738,7 +7740,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7748,25 +7750,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7787,183 +7789,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Licença" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7971,17 +7973,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7989,139 +7991,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8131,7 +8133,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8141,69 +8143,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8211,125 +8213,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8337,7 +8339,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8361,7 +8363,7 @@ msgstr "Caminho" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8398,79 +8400,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8478,36 +8480,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11764,10 +11766,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12818,7 +12820,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13463,6 +13465,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "Tipo" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14364,136 +14617,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14501,113 +14768,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14616,15 +14883,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14632,34 +14899,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14667,15 +14934,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "FPS" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14683,51 +14950,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14735,102 +15002,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14838,44 +15105,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16784,7 +17051,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16809,8 +17076,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16845,7 +17112,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16890,16 +17157,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16995,7 +17262,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17124,7 +17391,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17264,7 +17531,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17279,7 +17546,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17379,44 +17646,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17425,17 +17692,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17447,7 +17714,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17459,25 +17726,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17485,61 +17752,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17550,29 +17817,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Ferramentas" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17689,9 +17956,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17700,8 +17967,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17940,8 +18207,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18200,7 +18467,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18248,7 +18515,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18386,7 +18653,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18419,10 +18686,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18855,16 +19118,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18907,6 +19170,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19230,8 +19494,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19245,14 +19509,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19284,67 +19548,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19353,334 +19617,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19688,11 +19952,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19701,30 +19965,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19732,11 +19996,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19746,11 +20010,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Profundidade" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19759,66 +20023,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19826,38 +20090,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19868,13 +20132,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19917,8 +20181,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19929,7 +20193,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19957,56 +20221,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20014,26 +20278,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20041,23 +20305,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20066,129 +20330,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20196,111 +20459,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20330,61 +20593,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20392,7 +20656,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20400,42 +20664,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20443,31 +20707,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20482,186 +20746,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20675,38 +20939,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20715,44 +20979,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20760,27 +21024,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20788,7 +21052,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20796,13 +21060,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20811,113 +21075,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20925,110 +21189,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21036,12 +21300,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21054,213 +21318,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21268,38 +21532,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21309,149 +21573,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21459,143 +21723,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21603,78 +21868,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21715,10 +21980,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21770,11 +22035,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21810,7 +22075,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21821,8 +22086,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21837,23 +22102,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21864,7 +22130,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22078,9 +22344,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22088,46 +22354,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22135,92 +22402,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22242,28 +22508,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22272,7 +22537,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22283,7 +22548,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22293,50 +22558,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22344,137 +22609,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22482,31 +22756,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22520,45 +22794,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22566,68 +22845,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22635,14 +22914,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22655,8 +22934,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22700,7 +22979,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30179,14 +30458,14 @@ msgid "Audio" msgstr "Áudio" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30206,40 +30485,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30247,37 +30530,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30285,7 +30568,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30295,79 +30578,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30375,7 +30656,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30387,39 +30668,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30428,11 +30709,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30440,51 +30721,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30492,55 +30773,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30549,11 +30830,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30833,10 +31114,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32695,1532 +32972,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40212,7 +38963,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40600,226 +39351,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47265,9 +46135,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47321,7 +46191,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51918,6 +50788,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/ro.po b/weblate/ro.po index 1880a6d50b..f2fb12fda7 100644 --- a/weblate/ro.po +++ b/weblate/ro.po @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-18 06:42+0000\n" "Last-Translator: Calin Sopterean \n" "Language-Team: Romanian ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3287,109 +3289,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3397,55 +3399,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3453,57 +3455,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3513,17 +3515,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3531,7 +3533,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3539,55 +3541,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3595,24 +3597,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6356,7 +6358,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6379,7 +6381,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6390,8 +6392,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6413,7 +6415,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6477,27 +6479,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6505,17 +6507,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6525,54 +6527,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6581,7 +6583,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6590,18 +6592,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6609,7 +6611,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6617,14 +6619,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6634,60 +6636,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6697,11 +6699,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6709,7 +6711,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6717,15 +6719,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6734,38 +6736,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6774,20 +6776,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6795,15 +6797,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6952,7 +6954,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -6992,7 +6994,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7036,7 +7038,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7060,7 +7062,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7096,7 +7098,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7116,14 +7118,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7133,11 +7135,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7145,7 +7147,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7159,7 +7161,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7174,7 +7176,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7298,7 +7300,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7340,8 +7342,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7375,7 +7377,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7401,19 +7403,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7438,7 +7440,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7461,7 +7463,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7479,7 +7481,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7496,8 +7498,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7532,7 +7534,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7703,7 +7705,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7713,25 +7715,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7752,183 +7754,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Licență" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7936,17 +7938,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7954,139 +7956,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8096,7 +8098,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8106,69 +8108,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8176,125 +8178,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8302,7 +8304,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8326,7 +8328,7 @@ msgstr "Cale" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8363,79 +8365,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8443,36 +8445,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11720,10 +11722,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12774,7 +12776,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13419,6 +13421,256 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14320,136 +14572,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14457,113 +14723,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14572,15 +14838,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14588,34 +14854,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14623,15 +14889,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14639,51 +14905,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14691,102 +14957,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14794,44 +15060,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16740,7 +17006,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16765,8 +17031,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16801,7 +17067,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16846,16 +17112,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16951,7 +17217,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17080,7 +17346,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17220,7 +17486,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17235,7 +17501,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17335,44 +17601,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17381,17 +17647,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17403,7 +17669,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17415,25 +17681,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17441,61 +17707,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17506,29 +17772,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Unelte" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17645,9 +17911,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17656,8 +17922,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17896,8 +18162,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18156,7 +18422,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18204,7 +18470,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18342,7 +18608,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18375,10 +18641,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18811,16 +19073,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18863,6 +19125,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19186,8 +19449,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19201,14 +19464,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19240,67 +19503,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19309,334 +19572,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19644,11 +19907,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19657,30 +19920,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19688,11 +19951,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19702,11 +19965,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19715,66 +19978,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19782,38 +20045,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19824,13 +20087,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19873,8 +20136,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19885,7 +20148,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19913,56 +20176,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19970,26 +20233,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -19997,23 +20260,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20022,129 +20285,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20152,111 +20414,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20286,61 +20548,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20348,7 +20611,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20356,42 +20619,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20399,31 +20662,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20438,186 +20701,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20631,38 +20894,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20671,44 +20934,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20716,27 +20979,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20744,7 +21007,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20752,13 +21015,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20767,113 +21030,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20881,110 +21144,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -20992,12 +21255,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21010,213 +21273,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21224,38 +21487,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21265,149 +21528,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21415,143 +21678,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21559,78 +21823,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21671,10 +21935,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21726,11 +21990,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21766,7 +22030,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21777,8 +22041,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21793,23 +22057,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21820,7 +22085,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22034,9 +22299,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22044,46 +22309,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22091,92 +22357,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22198,28 +22463,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22228,7 +22492,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22239,7 +22503,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22249,50 +22513,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22300,137 +22564,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22438,31 +22711,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22476,45 +22749,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22522,68 +22800,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22591,14 +22869,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22611,8 +22889,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22656,7 +22934,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30135,14 +30413,14 @@ msgid "Audio" msgstr "Sunet" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30162,40 +30440,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30203,37 +30485,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30241,7 +30523,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30251,79 +30533,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30331,7 +30611,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30343,39 +30623,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30384,11 +30664,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30396,51 +30676,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30448,55 +30728,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30505,11 +30785,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30789,10 +31069,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32651,1532 +32927,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40168,7 +38918,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40556,226 +39306,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47221,9 +46090,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47277,7 +46146,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51873,6 +50742,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/ru.po b/weblate/ru.po index d4d6aa2d96..5f87031540 100644 --- a/weblate/ru.po +++ b/weblate/ru.po @@ -27,7 +27,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-18 06:42+0000\n" "Last-Translator: ijet \n" "Language-Team: Russian ` node lets us draw our UI elements " @@ -4302,23 +4309,23 @@ msgstr "" "информация не покрывалась какими-либо игровыми элементами, такими как игрок " "или мобы." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "HUD отображает следующую информацию:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "Счет, измененный ``ScoreTimer``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "Сообщение, например \"Game Over\" или \"Get Ready!\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "Кнопка \"Start\" чтобы начать игру." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 #, fuzzy msgid "" "The basic node for UI elements is :ref:`Control `. To create " @@ -4330,29 +4337,29 @@ msgstr "" "`Control ` nodes: :ref:`Label ` и :ref:`Button " "`." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 #, fuzzy msgid "Create the following as children of the ``HUD`` node:" msgstr "Создайте в качестве потомка узла '' HUD'' следующие:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr ":ref:`Label` названный ``ScoreLabel``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr ":ref:`Label ` названный ``MessageLabel``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 #, fuzzy msgid ":ref:`Button ` named ``StartButton``." msgstr ":ref:`Кнопка ` с именем ``StartButto" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr ":ref:`Timer ` названный ``MessageTimer``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -4369,7 +4376,7 @@ msgstr "" "`doc_design_interfaces_with_the_control_nodes` для получения более подробной " "информации." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" @@ -4377,7 +4384,7 @@ msgstr "" "Организуйте узлы, как показано ниже. Нажмите кнопку \"Якорь\" для установки " "узла управления якорем:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" @@ -4385,98 +4392,98 @@ msgstr "" "Можно перетаскивать узлы, чтобы разместить их вручную, или для более точного " "размещения, используйте следующие параметры:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 #, fuzzy msgid "ScoreLabel" msgstr "ScoreLabel" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "``Layout``: \"Center Top\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "``Margin``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "Left: ``-25``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "Top: ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "Right: ``25``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "Bottom: ``100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "Text: ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "MessageLabel" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "``Layout``: \"Center\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "Left: ``-200``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "Top: ``-150``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "Right: ``200``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "Bottom: ``0``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "Text: ``Dodge the Creeps!``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "StartButton" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "``Layout``: \"Center Bottom\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "Left: ``-100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "Top: ``-200``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "Right: ``100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "Bottom: ``-100``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "Text: ``Start``" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -4488,11 +4495,11 @@ msgstr "" "Regular.ttf\". Чтобы использовать этот шрифт, выполните следующие действия " "для каждой из трех узлов ``Control``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "Под \"Custom Fonts\", выберите \"New DynamicFont\"" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " @@ -4502,17 +4509,17 @@ msgstr "" "\" и выберите \"Xolonium-Regular.ttf\" . Необходимо также установить размер " "шрифта ``Size``. Значение ``64`` работает хорошо." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "Теперь добавьте этот сценарий '' HUD'':" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " @@ -4522,7 +4529,7 @@ msgstr "" "например, \"приготовиться\". На ``MessageTimer``, измените ``Wait Time`` до " "``2`` и измените ``One Shot`` установить на \"On\"." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." @@ -4531,21 +4538,21 @@ msgstr "" "Over\" на 2 секунды, затем вернуться к экрану названия и появится кнопка " "\"Start\"." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "Эта функция вызывается в ``Main`` всякий раз, когда изменяется оценка." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "Подключение к главной HUD" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -4556,7 +4563,7 @@ msgstr "" "``HUD`` сцену поместите в нижнюю часть дерева ``Main``. Дерево должно " "выглядеть так, поэтому убедитесь, что вы ничего не пропустили:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" @@ -4564,7 +4571,7 @@ msgstr "" "Теперь нам нужно подключить ``HUD`` функцию для ``Main`` скрипта. Для этого " "требуется несколько дополнений к ``Main`` сцены:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." @@ -4572,18 +4579,18 @@ msgstr "" "Во вкладке Узел подключите к HUD сигнал ``start_game`` и ``new_game()`` " "функций." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" "В ``new_game()``, обновит счет дисплея и покажет сообщение \"Get Ready\":" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "В ``game_over()`` нам нужно вызвать соответствующую функцию ``HUD``:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" @@ -4591,7 +4598,7 @@ msgstr "" "Наконец добавьте в ``_on_ScoreTimer_timeout()`` для синхронизации " "отображения с меняющемся очками:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." @@ -4599,11 +4606,11 @@ msgstr "" "Теперь вы готовы к игре! Нажмите на кнопку \"Запустить проект\" или F5. Вам " "будет предложено выбрать основную сцену, выбирайте ``Main.tscn``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "Завершение" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " @@ -4614,12 +4621,12 @@ msgstr "" "игрового опыта. Не стесняйтесь совершенствовать геймплей вашими собственными " "идеями." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "Фон" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -4635,7 +4642,7 @@ msgstr "" "свойство: ``Color``. Выберите цвет, который вам нравится и измените размер " "``ColorRect``, так чтобы он покрывал экран." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." @@ -4643,11 +4650,11 @@ msgstr "" "Вы также можете добавить фоновое изображение, если у вас оно есть, с помощью " "``Sprite``узла." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "Звуковые эффекты" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -4659,7 +4666,7 @@ msgstr "" "файла: \"House In a Forest Loop.ogg\" для фоновой музыки и \"gameover.wav\", " "когда игрок проигрывает." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -4671,7 +4678,7 @@ msgstr "" "``DeathSound``. На каждом из них, нажмите на кнопку ``Stream`` свойствах " "выберите \"загрузить\" и добавьте соответствующий звуковой файл." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." @@ -4679,16 +4686,16 @@ msgstr "" "Для воспроизведения музыки, добавьте ``$Music.play()`` функцию в " "``new_game()`` и ``$Music.stop()`` в ``game_over()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "Наконец, добавить ``$DeathSound.play()`` в ``game_over()``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "Частицы" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " @@ -4698,7 +4705,7 @@ msgstr "" "игрока. Выберите свою ``Player`` сцену и добавьте :ref:`Particles2D " "` узел под названием ``Trail``." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " @@ -4708,7 +4715,7 @@ msgstr "" "стесняйтесь экспериментировать и создавать различные эффекты. Для эффекта в " "этом примере используйте следующие параметры:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" @@ -4716,7 +4723,7 @@ msgstr "" "Также нужно создать ``Material``, нажав на ````, а затем на \"New " "ParticlesMaterial\". Параметры для этого приведены ниже:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " @@ -4726,7 +4733,7 @@ msgstr "" "градиент, принимал alpha (прозрачность) спрайта от 0.5 (полупрозрачным) до " "0,0 (полностью прозрачный)." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" @@ -4734,7 +4741,7 @@ msgstr "" "Нажмите кнопку \"Новый GradientTexture\", в \"Gradient\", нажмите кнопку " "\"Новый Gradient\". Вы увидите окно, как это:" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -4746,7 +4753,7 @@ msgstr "" "''A'' (альфа) сдвинуть ползунок на половину. Для второго установите ползунок " "до конца в ''0''." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." @@ -4754,11 +4761,11 @@ msgstr "" "См. :ref:`Particles2D ` для более подробной информации по " "использованию эффекта частиц." -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "Файлы проекта" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" @@ -4767,7 +4774,7 @@ msgstr "" "kidscancode/Godot3_dodge/releases" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "Экспорт" @@ -7552,7 +7559,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -7575,7 +7582,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -7586,8 +7593,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -7609,7 +7616,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -7673,27 +7680,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -7701,17 +7708,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -7721,54 +7728,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -7777,7 +7784,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -7786,18 +7793,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -7805,7 +7812,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -7813,14 +7820,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -7830,60 +7837,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -7893,11 +7900,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -7905,7 +7912,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -7913,15 +7920,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -7930,38 +7937,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -7970,20 +7977,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -7991,15 +7998,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -8148,7 +8155,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -8188,7 +8195,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -8232,7 +8239,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -8256,7 +8263,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -8292,7 +8299,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -8312,14 +8319,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -8329,11 +8336,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -8341,7 +8348,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -8355,7 +8362,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -8370,7 +8377,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -8494,7 +8501,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -8536,8 +8543,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -8571,7 +8578,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -8597,19 +8604,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -8634,7 +8641,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -8657,7 +8664,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -8675,7 +8682,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -8692,8 +8699,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -8728,7 +8735,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -8899,7 +8906,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -8909,25 +8916,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -8948,183 +8955,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Лицензия" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -9132,17 +9139,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -9150,139 +9157,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -9292,7 +9299,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -9302,69 +9309,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -9372,125 +9379,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -9498,7 +9505,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -9522,7 +9529,7 @@ msgstr "Путь" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -9559,79 +9566,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -9639,36 +9646,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -13132,10 +13139,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -14186,7 +14193,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -14831,6 +14838,259 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Нет никаких ограничений в использовании Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "Тип" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +#, fuzzy +msgid "There are the following caveats:" +msgstr "Сцена Моба будет использовать следующие узлы:" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -15732,136 +15992,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -15869,113 +16143,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -15984,15 +16258,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -16000,34 +16274,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -16035,15 +16309,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "FPS" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -16051,51 +16325,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -16103,102 +16377,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -16206,44 +16480,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -18152,7 +18426,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -18177,8 +18451,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -18213,7 +18487,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -18258,16 +18532,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -18363,7 +18637,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -18492,7 +18766,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -18632,7 +18906,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -18647,7 +18921,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -18747,44 +19021,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -18793,17 +19067,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -18815,7 +19089,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -18827,25 +19101,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -18853,61 +19127,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -18918,29 +19192,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Инструменты" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -19057,9 +19331,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -19068,8 +19342,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -19310,8 +19584,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -19570,7 +19844,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -19618,7 +19892,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -19756,7 +20030,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -19789,10 +20063,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -20225,16 +20495,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -20277,6 +20547,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -20600,8 +20871,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -20615,14 +20886,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -20654,67 +20925,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -20723,334 +20994,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -21058,11 +21329,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -21071,30 +21342,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -21102,11 +21373,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -21116,11 +21387,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Глубина" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -21129,66 +21400,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -21196,38 +21467,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -21238,13 +21509,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -21287,8 +21558,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -21299,7 +21570,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -21327,56 +21598,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -21384,26 +21655,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -21411,23 +21682,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -21436,129 +21707,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -21566,111 +21836,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -21700,61 +21970,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -21762,7 +22033,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -21770,42 +22041,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -21813,31 +22084,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -21852,186 +22123,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -22045,38 +22316,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -22085,44 +22356,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -22130,27 +22401,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -22158,7 +22429,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -22166,13 +22437,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -22181,113 +22452,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -22295,110 +22566,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -22406,12 +22677,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -22424,213 +22695,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -22638,38 +22909,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -22679,149 +22950,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -22829,143 +23100,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -22973,78 +23245,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -23085,10 +23357,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -23140,11 +23412,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -23180,7 +23452,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -23191,8 +23463,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -23207,23 +23479,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -23234,7 +23507,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -23448,9 +23721,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -23458,46 +23731,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -23505,92 +23779,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -23612,28 +23885,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -23642,7 +23914,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -23653,7 +23925,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -23663,50 +23935,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -23714,137 +23986,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -23852,31 +24133,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -23890,45 +24171,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -23936,68 +24222,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -24005,14 +24291,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -24025,8 +24311,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -24070,7 +24356,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -31554,14 +31840,14 @@ msgid "Audio" msgstr "Аудио" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -31581,40 +31867,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -31622,37 +31912,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -31660,7 +31950,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -31670,79 +31960,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -31750,7 +32038,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -31762,39 +32050,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -31803,11 +32091,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -31815,51 +32103,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -31867,55 +32155,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -31924,11 +32212,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -32208,10 +32496,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -34070,1532 +34354,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -41587,7 +40345,7 @@ msgid "Or alternatively, set it via function:" msgstr "Или, в качестве альтернативы, установите его через функцию:" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -41982,226 +40740,348 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 +#, fuzzy msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" +"Для получения дополнительной информации о самих событиях посмотрите " +"руководство :ref:`doc_inputevent`." + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -48651,9 +47531,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -48707,7 +47587,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -53305,6 +52185,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/sk.po b/weblate/sk.po index d7d026ae0d..49f02af35e 100644 --- a/weblate/sk.po +++ b/weblate/sk.po @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-15 17:43+0000\n" "Last-Translator: MineGame 159 \n" "Language-Team: Slovak ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3246,109 +3248,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3356,55 +3358,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3412,57 +3414,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3472,17 +3474,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3490,7 +3492,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3498,55 +3500,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3554,24 +3556,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6315,7 +6317,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6338,7 +6340,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6349,8 +6351,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6372,7 +6374,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6436,27 +6438,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6464,17 +6466,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6484,54 +6486,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6540,7 +6542,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6549,18 +6551,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6568,7 +6570,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6576,14 +6578,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6593,60 +6595,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6656,11 +6658,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6668,7 +6670,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6676,15 +6678,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6693,38 +6695,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6733,20 +6735,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6754,15 +6756,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6911,7 +6913,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -6951,7 +6953,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -6995,7 +6997,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7019,7 +7021,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7055,7 +7057,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7075,14 +7077,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7092,11 +7094,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7104,7 +7106,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7118,7 +7120,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7133,7 +7135,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7257,7 +7259,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7299,8 +7301,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7334,7 +7336,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7360,19 +7362,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7397,7 +7399,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7420,7 +7422,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7438,7 +7440,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7455,8 +7457,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7491,7 +7493,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7662,7 +7664,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7672,25 +7674,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7711,183 +7713,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7895,17 +7897,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7913,139 +7915,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8055,7 +8057,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8065,69 +8067,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8135,125 +8137,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8261,7 +8263,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8285,7 +8287,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8322,79 +8324,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8402,36 +8404,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11679,10 +11681,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12733,7 +12735,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13378,6 +13380,256 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14279,136 +14531,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14416,113 +14682,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14531,15 +14797,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14547,34 +14813,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14582,15 +14848,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14598,51 +14864,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14650,102 +14916,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14753,44 +15019,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16699,7 +16965,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16724,8 +16990,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16760,7 +17026,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16805,16 +17071,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16910,7 +17176,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17039,7 +17305,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17179,7 +17445,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17194,7 +17460,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17294,44 +17560,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17340,17 +17606,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17362,7 +17628,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17374,25 +17640,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17400,61 +17666,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17465,29 +17731,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17604,9 +17870,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17615,8 +17881,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17855,8 +18121,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18115,7 +18381,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18163,7 +18429,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18301,7 +18567,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18334,10 +18600,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18770,16 +19032,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18822,6 +19084,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19145,8 +19408,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19160,14 +19423,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19199,67 +19462,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19268,334 +19531,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19603,11 +19866,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19616,30 +19879,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19647,11 +19910,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19661,11 +19924,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19674,66 +19937,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19741,38 +20004,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19783,13 +20046,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19832,8 +20095,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19844,7 +20107,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19872,56 +20135,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19929,26 +20192,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -19956,23 +20219,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -19981,129 +20244,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20111,111 +20373,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20245,61 +20507,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20307,7 +20570,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20315,42 +20578,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20358,31 +20621,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20397,186 +20660,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20590,38 +20853,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20630,44 +20893,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20675,27 +20938,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20703,7 +20966,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20711,13 +20974,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20726,113 +20989,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20840,110 +21103,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -20951,12 +21214,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -20969,213 +21232,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21183,38 +21446,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21224,149 +21487,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21374,143 +21637,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21518,78 +21782,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21630,10 +21894,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21685,11 +21949,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21725,7 +21989,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21736,8 +22000,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21752,23 +22016,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21779,7 +22044,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -21993,9 +22258,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22003,46 +22268,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22050,92 +22316,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22157,28 +22422,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22187,7 +22451,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22198,7 +22462,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22208,50 +22472,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22259,137 +22523,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22397,31 +22670,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22435,45 +22708,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22481,68 +22759,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22550,14 +22828,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22570,8 +22848,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22615,7 +22893,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30094,14 +30372,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30121,40 +30399,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30162,37 +30444,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30200,7 +30482,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30210,79 +30492,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30290,7 +30570,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30302,39 +30582,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30343,11 +30623,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30355,51 +30635,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30407,55 +30687,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30464,11 +30744,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30748,10 +31028,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32610,1532 +32886,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40127,7 +38877,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40515,226 +39265,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47180,9 +46049,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47236,7 +46105,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51832,6 +50701,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/sl.po b/weblate/sl.po index 7f07101797..829b8b08d0 100644 --- a/weblate/sl.po +++ b/weblate/sl.po @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-07 14:44+0000\n" "Last-Translator: matevž lapajne \n" "Language-Team: Slovenian ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3423,109 +3425,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3533,55 +3535,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3589,57 +3591,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3649,17 +3651,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3667,7 +3669,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3675,55 +3677,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3731,24 +3733,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6493,7 +6495,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6516,7 +6518,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6527,8 +6529,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6550,7 +6552,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6614,27 +6616,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6642,17 +6644,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6662,54 +6664,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6718,7 +6720,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6727,18 +6729,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6746,7 +6748,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6754,14 +6756,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6771,60 +6773,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6834,11 +6836,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6846,7 +6848,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6854,15 +6856,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6871,38 +6873,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6911,20 +6913,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6932,15 +6934,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7089,7 +7091,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7129,7 +7131,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7173,7 +7175,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7197,7 +7199,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7233,7 +7235,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7253,14 +7255,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7270,11 +7272,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7282,7 +7284,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7296,7 +7298,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7311,7 +7313,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7435,7 +7437,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7477,8 +7479,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7512,7 +7514,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7538,19 +7540,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7575,7 +7577,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7598,7 +7600,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7616,7 +7618,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7633,8 +7635,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7669,7 +7671,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7840,7 +7842,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7850,25 +7852,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7889,183 +7891,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Licenca" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8073,17 +8075,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8091,139 +8093,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8233,7 +8235,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8243,69 +8245,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8313,125 +8315,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8439,7 +8441,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8463,7 +8465,7 @@ msgstr "Pot" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8500,79 +8502,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8580,36 +8582,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11857,10 +11859,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12911,7 +12913,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13556,6 +13558,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Godot nima omejitve uporabe" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14457,136 +14710,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14594,113 +14861,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14709,15 +14976,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14725,34 +14992,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14760,15 +15027,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14776,51 +15043,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14828,102 +15095,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14931,44 +15198,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16877,7 +17144,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16902,8 +17169,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16938,7 +17205,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16983,16 +17250,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17088,7 +17355,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17217,7 +17484,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17357,7 +17624,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17372,7 +17639,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17472,44 +17739,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17518,17 +17785,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17540,7 +17807,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17552,25 +17819,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17578,61 +17845,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17643,29 +17910,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Orodja" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17782,9 +18049,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17793,8 +18060,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -18033,8 +18300,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18293,7 +18560,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18341,7 +18608,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18479,7 +18746,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18512,10 +18779,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18948,16 +19211,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -19000,6 +19263,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19323,8 +19587,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19338,14 +19602,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19377,67 +19641,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19446,334 +19710,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19781,11 +20045,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19794,30 +20058,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19825,11 +20089,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19839,11 +20103,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Globina" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19852,66 +20116,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19919,38 +20183,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19961,13 +20225,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -20010,8 +20274,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -20022,7 +20286,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -20050,56 +20314,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20107,26 +20371,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20134,23 +20398,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20159,129 +20423,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20289,111 +20552,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20423,61 +20686,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20485,7 +20749,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20493,42 +20757,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20536,31 +20800,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20575,186 +20839,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20768,38 +21032,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20808,44 +21072,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20853,27 +21117,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20881,7 +21145,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20889,13 +21153,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20904,113 +21168,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -21018,110 +21282,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21129,12 +21393,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21147,213 +21411,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21361,38 +21625,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21402,149 +21666,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21552,143 +21816,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21696,78 +21961,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21808,10 +22073,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21863,11 +22128,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21903,7 +22168,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21914,8 +22179,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21930,23 +22195,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21957,7 +22223,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22171,9 +22437,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22181,46 +22447,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22228,92 +22495,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22335,28 +22601,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22365,7 +22630,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22376,7 +22641,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22386,50 +22651,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22437,137 +22702,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22575,31 +22849,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22613,45 +22887,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22659,68 +22938,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22728,14 +23007,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22748,8 +23027,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22793,7 +23072,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30272,14 +30551,14 @@ msgid "Audio" msgstr "Zvok" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30299,40 +30578,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30340,37 +30623,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30378,7 +30661,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30388,79 +30671,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30468,7 +30749,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30480,39 +30761,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30521,11 +30802,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30533,51 +30814,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30585,55 +30866,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30642,11 +30923,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30926,10 +31207,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32788,1532 +33065,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40305,7 +39056,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40693,226 +39444,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47358,9 +46228,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47414,7 +46284,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -52010,6 +50880,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/sr_Latn.po b/weblate/sr_Latn.po index e084fdafc1..5a0ed16562 100644 --- a/weblate/sr_Latn.po +++ b/weblate/sr_Latn.po @@ -9,7 +9,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-05-15 08:41+0000\n" "Last-Translator: Milos Ponjavusic \n" "Language-Team: Serbian (latin) ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3350,109 +3352,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3460,55 +3462,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3516,57 +3518,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3576,17 +3578,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3594,7 +3596,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3602,55 +3604,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3658,24 +3660,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6419,7 +6421,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6442,7 +6444,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6453,8 +6455,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6476,7 +6478,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6540,27 +6542,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6568,17 +6570,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6588,54 +6590,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6644,7 +6646,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6653,18 +6655,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6672,7 +6674,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6680,14 +6682,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6697,60 +6699,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6760,11 +6762,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6772,7 +6774,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6780,15 +6782,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6797,38 +6799,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6837,20 +6839,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6858,15 +6860,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7015,7 +7017,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7055,7 +7057,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7099,7 +7101,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7123,7 +7125,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7159,7 +7161,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7179,14 +7181,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7196,11 +7198,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7208,7 +7210,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7222,7 +7224,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7237,7 +7239,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7361,7 +7363,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7403,8 +7405,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7438,7 +7440,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7464,19 +7466,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7501,7 +7503,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7524,7 +7526,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7542,7 +7544,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7559,8 +7561,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7595,7 +7597,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7766,7 +7768,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7776,25 +7778,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7815,183 +7817,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7999,17 +8001,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8017,139 +8019,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8159,7 +8161,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8169,69 +8171,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8239,125 +8241,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8365,7 +8367,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8389,7 +8391,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8426,79 +8428,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8506,36 +8508,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11783,10 +11785,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12837,7 +12839,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13482,6 +13484,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Ne postoje ograničenja prilikom korištenja Godot-a" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14383,136 +14636,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14520,113 +14787,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14635,15 +14902,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14651,34 +14918,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14686,15 +14953,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14702,51 +14969,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14754,102 +15021,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14857,44 +15124,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16803,7 +17070,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16828,8 +17095,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16864,7 +17131,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16909,16 +17176,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17014,7 +17281,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17143,7 +17410,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17283,7 +17550,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17298,7 +17565,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17398,44 +17665,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17444,17 +17711,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17466,7 +17733,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17478,25 +17745,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17504,61 +17771,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17569,29 +17836,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17708,9 +17975,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17719,8 +17986,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17959,8 +18226,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18219,7 +18486,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18267,7 +18534,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18405,7 +18672,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18438,10 +18705,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18874,16 +19137,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18926,6 +19189,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19249,8 +19513,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19264,14 +19528,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19303,67 +19567,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19372,334 +19636,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19707,11 +19971,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19720,30 +19984,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19751,11 +20015,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19765,11 +20029,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19778,66 +20042,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19845,38 +20109,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19887,13 +20151,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19936,8 +20200,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19948,7 +20212,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19976,56 +20240,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20033,26 +20297,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20060,23 +20324,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20085,129 +20349,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20215,111 +20478,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20349,61 +20612,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20411,7 +20675,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20419,42 +20683,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20462,31 +20726,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20501,186 +20765,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20694,38 +20958,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20734,44 +20998,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20779,27 +21043,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20807,7 +21071,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20815,13 +21079,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20830,113 +21094,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20944,110 +21208,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21055,12 +21319,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21073,213 +21337,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21287,38 +21551,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21328,149 +21592,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21478,143 +21742,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21622,78 +21887,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21734,10 +21999,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21789,11 +22054,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21829,7 +22094,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21840,8 +22105,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21856,23 +22121,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21883,7 +22149,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22097,9 +22363,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22107,46 +22373,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22154,92 +22421,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22261,28 +22527,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22291,7 +22556,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22302,7 +22567,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22312,50 +22577,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22363,137 +22628,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22501,31 +22775,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22539,45 +22813,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22585,68 +22864,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22654,14 +22933,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22674,8 +22953,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22719,7 +22998,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30198,14 +30477,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30225,40 +30504,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30266,37 +30549,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30304,7 +30587,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30314,79 +30597,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30394,7 +30675,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30406,39 +30687,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30447,11 +30728,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30459,51 +30740,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30511,55 +30792,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30568,11 +30849,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30852,10 +31133,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32714,1532 +32991,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40231,7 +38982,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40619,226 +39370,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47284,9 +46154,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47340,7 +46210,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51936,6 +50806,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/sv.po b/weblate/sv.po index caf5af4d48..98c49fbfbc 100644 --- a/weblate/sv.po +++ b/weblate/sv.po @@ -10,7 +10,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-12 18:44+0000\n" "Last-Translator: Tobias Björkdahl \n" "Language-Team: Swedish ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3261,109 +3263,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3371,55 +3373,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3427,57 +3429,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3487,17 +3489,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3505,7 +3507,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3513,55 +3515,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3569,24 +3571,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6330,7 +6332,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6353,7 +6355,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6364,8 +6366,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6387,7 +6389,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6451,27 +6453,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6479,17 +6481,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6499,54 +6501,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6555,7 +6557,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6564,18 +6566,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6583,7 +6585,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6591,14 +6593,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6608,60 +6610,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6671,11 +6673,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6683,7 +6685,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6691,15 +6693,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6708,38 +6710,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6748,20 +6750,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6769,15 +6771,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6926,7 +6928,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -6966,7 +6968,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7010,7 +7012,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7034,7 +7036,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7070,7 +7072,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7090,14 +7092,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7107,11 +7109,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7119,7 +7121,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7133,7 +7135,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7148,7 +7150,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7272,7 +7274,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7314,8 +7316,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7349,7 +7351,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7375,19 +7377,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7412,7 +7414,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7435,7 +7437,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7453,7 +7455,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7470,8 +7472,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7506,7 +7508,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7677,7 +7679,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7687,25 +7689,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7726,183 +7728,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7910,17 +7912,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7928,139 +7930,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8070,7 +8072,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8080,69 +8082,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8150,125 +8152,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8276,7 +8278,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8300,7 +8302,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8337,79 +8339,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8417,36 +8419,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11694,10 +11696,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12748,7 +12750,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13393,6 +13395,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "Typ" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14294,136 +14547,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14431,113 +14698,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14546,15 +14813,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14562,34 +14829,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14597,15 +14864,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14613,51 +14880,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14665,102 +14932,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14768,44 +15035,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16714,7 +16981,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16739,8 +17006,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16775,7 +17042,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16820,16 +17087,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16925,7 +17192,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17054,7 +17321,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17194,7 +17461,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17209,7 +17476,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17309,44 +17576,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17355,17 +17622,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17377,7 +17644,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17389,25 +17656,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17415,61 +17682,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17480,29 +17747,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17619,9 +17886,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17630,8 +17897,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17870,8 +18137,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18130,7 +18397,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18178,7 +18445,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18316,7 +18583,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18349,10 +18616,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18785,16 +19048,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18837,6 +19100,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19160,8 +19424,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19175,14 +19439,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19214,67 +19478,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19283,334 +19547,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19618,11 +19882,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19631,30 +19895,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19662,11 +19926,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19676,11 +19940,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19689,66 +19953,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19756,38 +20020,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19798,13 +20062,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19847,8 +20111,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19859,7 +20123,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19887,56 +20151,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19944,26 +20208,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -19971,23 +20235,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -19996,129 +20260,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20126,111 +20389,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20260,61 +20523,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20322,7 +20586,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20330,42 +20594,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20373,31 +20637,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20412,186 +20676,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20605,38 +20869,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20645,44 +20909,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20690,27 +20954,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20718,7 +20982,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20726,13 +20990,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20741,113 +21005,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20855,110 +21119,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -20966,12 +21230,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -20984,213 +21248,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21198,38 +21462,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21239,149 +21503,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21389,143 +21653,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21533,78 +21798,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21645,10 +21910,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21700,11 +21965,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21740,7 +22005,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21751,8 +22016,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21767,23 +22032,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21794,7 +22060,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22008,9 +22274,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22018,46 +22284,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22065,92 +22332,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22172,28 +22438,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22202,7 +22467,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22213,7 +22478,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22223,50 +22488,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22274,137 +22539,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22412,31 +22686,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22450,45 +22724,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22496,68 +22775,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22565,14 +22844,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22585,8 +22864,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22630,7 +22909,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30109,14 +30388,14 @@ msgid "Audio" msgstr "Ljud" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30136,40 +30415,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30177,37 +30460,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30215,7 +30498,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30225,79 +30508,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30305,7 +30586,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30317,39 +30598,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30358,11 +30639,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30370,51 +30651,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30422,55 +30703,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30479,11 +30760,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30763,10 +31044,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32625,1532 +32902,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40142,7 +38893,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40530,226 +39281,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47195,9 +46065,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47251,7 +46121,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51847,6 +50717,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/th.po b/weblate/th.po index c6c21948be..438e9ebdb2 100644 --- a/weblate/th.po +++ b/weblate/th.po @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-04-17 12:41+0000\n" "Last-Translator: Poommetee Ketson \n" "Language-Team: Thai ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3417,109 +3419,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3527,55 +3529,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3583,57 +3585,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3643,17 +3645,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3661,7 +3663,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3669,55 +3671,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3725,24 +3727,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6486,7 +6488,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6509,7 +6511,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6520,8 +6522,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6543,7 +6545,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6607,27 +6609,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6635,17 +6637,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6655,54 +6657,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6711,7 +6713,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6720,18 +6722,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6739,7 +6741,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6747,14 +6749,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6764,60 +6766,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6827,11 +6829,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6839,7 +6841,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6847,15 +6849,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6864,38 +6866,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6904,20 +6906,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6925,15 +6927,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7082,7 +7084,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7122,7 +7124,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7166,7 +7168,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7190,7 +7192,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7226,7 +7228,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7246,14 +7248,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7263,11 +7265,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7275,7 +7277,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7289,7 +7291,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7304,7 +7306,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7428,7 +7430,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7470,8 +7472,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7505,7 +7507,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7531,19 +7533,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7568,7 +7570,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7591,7 +7593,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7609,7 +7611,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7626,8 +7628,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7662,7 +7664,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7833,7 +7835,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7843,25 +7845,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7882,184 +7884,184 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 #, fuzzy msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "X11 (ลินุกซ์, \\*บีเอสดี)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8067,17 +8069,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8085,139 +8087,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8227,7 +8229,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8237,69 +8239,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8307,125 +8309,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8433,7 +8435,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8457,7 +8459,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8494,79 +8496,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8574,36 +8576,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11906,10 +11908,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12961,7 +12963,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13606,6 +13608,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "ไม่มีข้อจำกัดการใช้งาน Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14507,136 +14760,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14644,113 +14911,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14759,15 +15026,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14775,34 +15042,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14810,15 +15077,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14826,51 +15093,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14878,102 +15145,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14981,44 +15248,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16927,7 +17194,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16952,8 +17219,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16988,7 +17255,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -17033,16 +17300,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17138,7 +17405,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17267,7 +17534,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17407,7 +17674,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17422,7 +17689,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17522,44 +17789,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17568,17 +17835,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17590,7 +17857,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17602,25 +17869,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17628,61 +17895,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17693,29 +17960,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17832,9 +18099,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17843,8 +18110,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -18083,8 +18350,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18349,7 +18616,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18397,7 +18664,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18535,7 +18802,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18568,10 +18835,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -19004,16 +19267,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -19056,6 +19319,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19379,8 +19643,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19394,14 +19658,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19433,67 +19697,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19502,334 +19766,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19837,11 +20101,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19850,30 +20114,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19881,11 +20145,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19895,11 +20159,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19908,66 +20172,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19975,38 +20239,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -20017,13 +20281,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -20066,8 +20330,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -20078,7 +20342,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -20106,56 +20370,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20163,26 +20427,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20190,23 +20454,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20215,129 +20479,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20345,111 +20608,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20479,61 +20742,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20541,7 +20805,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20549,42 +20813,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20592,31 +20856,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20631,186 +20895,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20824,38 +21088,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20864,44 +21128,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20909,27 +21173,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20937,7 +21201,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20945,13 +21209,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20960,113 +21224,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -21074,110 +21338,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21185,12 +21449,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21203,213 +21467,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21417,38 +21681,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21458,149 +21722,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21608,143 +21872,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21752,78 +22017,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21864,10 +22129,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21919,11 +22184,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21959,7 +22224,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21970,8 +22235,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21986,23 +22251,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -22013,7 +22279,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22227,9 +22493,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22237,46 +22503,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22284,92 +22551,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22391,28 +22657,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22421,7 +22686,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22432,7 +22697,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22442,50 +22707,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22493,137 +22758,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22631,31 +22905,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22669,45 +22943,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22715,68 +22994,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22784,14 +23063,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22804,8 +23083,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22849,7 +23128,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30328,14 +30607,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30355,40 +30634,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30396,37 +30679,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30434,7 +30717,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30444,79 +30727,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30524,7 +30805,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30536,39 +30817,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30577,11 +30858,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30589,51 +30870,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30641,55 +30922,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30698,11 +30979,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30982,10 +31263,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32844,1532 +33121,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40361,7 +39112,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40749,226 +39500,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47414,9 +46284,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47470,7 +46340,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -52067,6 +50937,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/tr.po b/weblate/tr.po index 7abe558e7b..3c3ceafc71 100644 --- a/weblate/tr.po +++ b/weblate/tr.po @@ -13,7 +13,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-08 08:47+0000\n" "Last-Translator: Tuna Soncul \n" "Language-Team: Turkish ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3306,109 +3308,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3416,55 +3418,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3472,57 +3474,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3532,17 +3534,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3550,7 +3552,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3558,55 +3560,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "Parçacıklar" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3614,24 +3616,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6376,7 +6378,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6399,7 +6401,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6410,8 +6412,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6433,7 +6435,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6497,27 +6499,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6525,17 +6527,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6545,54 +6547,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6601,7 +6603,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6610,18 +6612,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6629,7 +6631,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6637,14 +6639,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6654,60 +6656,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6717,11 +6719,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6729,7 +6731,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6737,15 +6739,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6754,38 +6756,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6794,20 +6796,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6815,15 +6817,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6972,7 +6974,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7012,7 +7014,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7056,7 +7058,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7080,7 +7082,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7116,7 +7118,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7136,14 +7138,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7153,11 +7155,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7165,7 +7167,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7179,7 +7181,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7194,7 +7196,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7318,7 +7320,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7360,8 +7362,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7395,7 +7397,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7421,19 +7423,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7458,7 +7460,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7481,7 +7483,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7499,7 +7501,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7516,8 +7518,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7552,7 +7554,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7723,7 +7725,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7733,25 +7735,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7772,183 +7774,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Lisans" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7956,17 +7958,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7974,139 +7976,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8116,7 +8118,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8126,69 +8128,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8196,125 +8198,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8322,7 +8324,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8346,7 +8348,7 @@ msgstr "Yol" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8383,79 +8385,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8463,36 +8465,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11743,10 +11745,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12798,7 +12800,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13443,6 +13445,258 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Godot'ta kullanım kısıtlaması yoktur" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "Tür" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14344,136 +14598,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14481,113 +14749,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14596,15 +14864,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14612,34 +14880,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14647,15 +14915,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "FPS" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14663,51 +14931,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14715,102 +14983,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14818,44 +15086,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16764,7 +17032,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16789,8 +17057,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16825,7 +17093,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16870,16 +17138,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16975,7 +17243,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17104,7 +17372,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17244,7 +17512,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17259,7 +17527,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17359,44 +17627,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17405,17 +17673,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17427,7 +17695,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17439,25 +17707,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17465,61 +17733,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17530,29 +17798,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Araçlar" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17669,9 +17937,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17680,8 +17948,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17920,8 +18188,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18180,7 +18448,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18228,7 +18496,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18366,7 +18634,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18399,10 +18667,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18835,16 +19099,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18887,6 +19151,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19210,8 +19475,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19225,14 +19490,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19264,67 +19529,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19333,334 +19598,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19668,11 +19933,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19681,30 +19946,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19712,11 +19977,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19726,11 +19991,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Derinlik" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19739,66 +20004,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19806,38 +20071,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19848,13 +20113,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19897,8 +20162,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19909,7 +20174,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19937,56 +20202,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -19994,26 +20259,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20021,23 +20286,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20046,129 +20311,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20176,111 +20440,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20310,61 +20574,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20372,7 +20637,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20380,42 +20645,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20423,31 +20688,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20462,186 +20727,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20655,38 +20920,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20695,44 +20960,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20740,27 +21005,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20768,7 +21033,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20776,13 +21041,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20791,113 +21056,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20905,110 +21170,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21016,12 +21281,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21034,213 +21299,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21248,38 +21513,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21289,149 +21554,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21439,143 +21704,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21583,78 +21849,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21695,10 +21961,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21750,11 +22016,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21790,7 +22056,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21801,8 +22067,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21817,23 +22083,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21844,7 +22111,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22058,9 +22325,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22068,46 +22335,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22115,92 +22383,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22222,28 +22489,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22252,7 +22518,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22263,7 +22529,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22273,50 +22539,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22324,137 +22590,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22462,31 +22737,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22500,45 +22775,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22546,68 +22826,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22615,14 +22895,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22635,8 +22915,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22680,7 +22960,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30159,14 +30439,14 @@ msgid "Audio" msgstr "Ses" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30186,40 +30466,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30227,37 +30511,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30265,7 +30549,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30275,79 +30559,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30355,7 +30637,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30367,39 +30649,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30408,11 +30690,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30420,51 +30702,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30472,55 +30754,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30529,11 +30811,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30813,10 +31095,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32675,1532 +32953,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40193,7 +38945,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40581,226 +39333,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47246,9 +46117,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47302,7 +46173,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51899,6 +50770,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/uk.po b/weblate/uk.po index db9a2f3bcf..d0ea603456 100644 --- a/weblate/uk.po +++ b/weblate/uk.po @@ -9,7 +9,7 @@ msgid "" msgstr "" "Project-Id-Version: Ukrainian (Godot Engine)\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-15 12:45+0000\n" "Last-Translator: Максим Якимчук \n" "Language-Team: Ukrainian ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3501,109 +3505,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3611,55 +3615,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3667,57 +3671,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "Завершальна обробка" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "Тло" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3727,17 +3731,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "Звукові ефекти" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3745,7 +3749,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3753,55 +3757,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "Частинки" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3809,24 +3813,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "Файли проекту" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "Експортування" @@ -6570,7 +6574,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6593,7 +6597,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6604,8 +6608,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6627,7 +6631,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6691,27 +6695,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6719,17 +6723,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6739,54 +6743,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6795,7 +6799,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6804,18 +6808,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6823,7 +6827,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6831,14 +6835,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6848,60 +6852,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6911,11 +6915,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6923,7 +6927,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6931,15 +6935,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6948,38 +6952,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6988,20 +6992,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -7009,15 +7013,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7166,7 +7170,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7206,7 +7210,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7250,7 +7254,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7274,7 +7278,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7310,7 +7314,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7330,14 +7334,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7347,11 +7351,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7359,7 +7363,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7373,7 +7377,7 @@ msgstr "Файлова система" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7388,7 +7392,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "Реалізація" @@ -7512,7 +7516,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7554,8 +7558,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7589,7 +7593,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7615,19 +7619,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7652,7 +7656,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7675,7 +7679,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7693,7 +7697,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7710,8 +7714,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7746,7 +7750,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7917,7 +7921,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7927,25 +7931,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "і" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7966,183 +7970,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "Відмінності" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "Unity" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "Godot" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "Ліцензія" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "ОС (редактор)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "Windows, macOS, X11 (Linux, \\*BSD)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "ОС (експорт)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "**Настільні:** Windows, macOS, Linux" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "**Мобільні:** Android, iOS, Windows Phone, Tizen" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "Visual Studio або VS Code" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "Редактор" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8150,17 +8154,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8168,139 +8172,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "Цегла" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8310,7 +8314,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8320,69 +8324,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8390,125 +8394,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "Дизайн" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8516,7 +8520,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8540,7 +8544,7 @@ msgstr "Шлях" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8577,79 +8581,79 @@ msgstr "" msgid "Creating a project" msgstr "Як створити проект" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "Діагностика" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8657,36 +8661,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11934,10 +11938,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12988,7 +12992,7 @@ msgstr "get_scale()" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "Scale" @@ -13633,6 +13637,261 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +#, fuzzy +msgid "Build Pipeline Integration" +msgstr "Налаштування збирання:" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "Матеріали" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +#, fuzzy +msgid "Export of Blender materials" +msgstr "Шаблони експортування" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "Освітлення" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Немає ніяких обмежень на використання Godot" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +#, fuzzy +msgid "Physics Properties" +msgstr "Властивості вузла" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "За типом" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14534,136 +14793,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "Параметри імпортування" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "Вузли:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "Матеріали" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "Місце" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14671,113 +14944,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "Стиснути" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "Додаткові дані:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14786,15 +15059,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14802,34 +15075,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14837,15 +15110,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "Кадри за секунду" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14853,51 +15126,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "Кліпи" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14905,102 +15178,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -15008,44 +15281,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16955,7 +17228,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16980,8 +17253,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -17016,7 +17289,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -17061,16 +17334,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17166,7 +17439,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17295,7 +17568,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17435,7 +17708,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17450,7 +17723,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17550,44 +17823,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17596,17 +17869,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17618,7 +17891,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17630,25 +17903,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "Результат:" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17656,61 +17929,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17721,29 +17994,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "Інструменти" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17860,9 +18133,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17871,8 +18144,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -18111,8 +18384,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18371,7 +18644,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18419,7 +18692,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "Середовище" @@ -18557,7 +18830,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18590,10 +18863,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "Освітлення" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -19026,16 +19295,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -19078,6 +19347,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "Обробка" @@ -19401,8 +19671,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19416,14 +19686,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19455,67 +19725,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19524,334 +19794,334 @@ msgstr "" msgid "Parameters" msgstr "Параметри" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "Режим змішування" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "Товщина лінії" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "Розмір крапки" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "Збільшити" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "Альбедо" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19859,11 +20129,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19872,30 +20142,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "Анізотропія" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19903,11 +20173,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19917,11 +20187,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "Глибина" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19930,66 +20200,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "Подробиці" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19997,38 +20267,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -20039,13 +20309,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -20088,8 +20358,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -20100,7 +20370,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -20128,56 +20398,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20185,26 +20455,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20212,23 +20482,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20237,129 +20507,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "Прожектор" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20367,111 +20636,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20501,61 +20770,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20563,7 +20833,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20571,42 +20841,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20614,31 +20884,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20653,186 +20923,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "Відбиття" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "Якість" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20846,38 +21116,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20886,44 +21156,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20931,27 +21201,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20959,7 +21229,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20967,13 +21237,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20982,113 +21252,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -21096,110 +21366,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21207,12 +21477,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21225,213 +21495,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "Туман" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21439,38 +21709,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21480,149 +21750,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21630,143 +21900,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "Німб" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21774,78 +22045,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "Коригування" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21886,10 +22157,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21941,11 +22212,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21981,7 +22252,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21992,8 +22263,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -22008,23 +22279,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -22035,7 +22307,7 @@ msgstr "Експозиція" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22249,9 +22521,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22259,46 +22531,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22306,92 +22579,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "Цільова поверхня" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "Початкова сітка" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "Вісь вгору сітки" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "Випадкове обертання" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "Випадковий нахил" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "Випадковий масштаб" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "Сума" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22413,28 +22685,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22443,7 +22714,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22454,7 +22725,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22464,50 +22735,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22515,137 +22786,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22653,31 +22933,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "ЩЕ НЕ НАПИСАНО." @@ -22691,45 +22971,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22737,68 +23022,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22806,14 +23091,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22826,8 +23111,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22871,7 +23156,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30350,14 +30635,14 @@ msgid "Audio" msgstr "Аудіо" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30377,40 +30662,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30418,37 +30707,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30456,7 +30745,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30466,79 +30755,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "Підсилення сигналу" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "Хорова" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "Компресор" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30546,7 +30833,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30558,39 +30845,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "Затримка" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "Викривлення" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30599,11 +30886,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30611,51 +30898,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "Обмежувач" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "Фазер" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30663,55 +30950,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "Відлуння" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30720,11 +31007,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -31004,10 +31291,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32866,1532 +33149,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "Що" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "Вектор" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "Генератор" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40383,7 +39140,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "Ввід" @@ -40771,226 +39528,346 @@ msgstr "4 панелі перегляду" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "Демонстраційне вікно" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "Фотоапарат" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" -msgstr "Захоплення" - #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "Захоплення" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:154 -msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" +#: ../../docs/tutorials/viewports/viewports.rst:163 +#, fuzzy +msgid "Viewport Container" msgstr "ViewportContainer" -#: ../../docs/tutorials/viewports/viewports.rst:161 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47440,9 +46317,9 @@ msgstr "Користування модулем" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47496,7 +46373,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -52097,6 +50974,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "Вектор" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "Список" @@ -57071,6 +55952,18 @@ msgid "" "`_" msgstr "" +#~ msgid "What" +#~ msgstr "Що" + +#~ msgid "Generator" +#~ msgstr "Генератор" + +#~ msgid "Viewport" +#~ msgstr "Демонстраційне вікно" + +#~ msgid "Camera" +#~ msgstr "Фотоапарат" + #~ msgid "Direction" #~ msgstr "Напрямок" diff --git a/weblate/vi.po b/weblate/vi.po index 5ef9204663..3e46d9800d 100644 --- a/weblate/vi.po +++ b/weblate/vi.po @@ -9,7 +9,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-05-17 02:42+0000\n" "Last-Translator: mth2610 \n" "Language-Team: Vietnamese ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3320,109 +3322,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3430,55 +3432,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3486,57 +3488,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3546,17 +3548,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3564,7 +3566,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3572,55 +3574,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3628,24 +3630,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6389,7 +6391,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6412,7 +6414,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6423,8 +6425,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6446,7 +6448,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6510,27 +6512,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6538,17 +6540,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6558,54 +6560,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6614,7 +6616,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6623,18 +6625,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6642,7 +6644,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6650,14 +6652,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6667,60 +6669,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6730,11 +6732,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6742,7 +6744,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6750,15 +6752,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6767,38 +6769,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6807,20 +6809,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6828,15 +6830,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -6985,7 +6987,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7025,7 +7027,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7069,7 +7071,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7093,7 +7095,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7129,7 +7131,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7149,14 +7151,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7166,11 +7168,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7178,7 +7180,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7192,7 +7194,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7207,7 +7209,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7331,7 +7333,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7373,8 +7375,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7408,7 +7410,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7434,19 +7436,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7471,7 +7473,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7494,7 +7496,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7512,7 +7514,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7529,8 +7531,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7565,7 +7567,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7736,7 +7738,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7746,25 +7748,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7785,183 +7787,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -7969,17 +7971,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -7987,139 +7989,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8129,7 +8131,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8139,69 +8141,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8209,125 +8211,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8335,7 +8337,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8359,7 +8361,7 @@ msgstr "" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8396,79 +8398,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8476,36 +8478,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11753,10 +11755,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12807,7 +12809,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13452,6 +13454,256 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +msgid "There are some things to note:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14353,136 +14605,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14490,113 +14756,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14605,15 +14871,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14621,34 +14887,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14656,15 +14922,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14672,51 +14938,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14724,102 +14990,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14827,44 +15093,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16773,7 +17039,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16798,8 +17064,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16834,7 +17100,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16879,16 +17145,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -16984,7 +17250,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17113,7 +17379,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17253,7 +17519,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17268,7 +17534,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17368,44 +17634,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17414,17 +17680,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17436,7 +17702,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17448,25 +17714,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17474,61 +17740,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17539,29 +17805,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17678,9 +17944,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17689,8 +17955,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17929,8 +18195,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18189,7 +18455,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18237,7 +18503,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18375,7 +18641,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18408,10 +18674,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18844,16 +19106,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18896,6 +19158,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19219,8 +19482,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19234,14 +19497,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19273,67 +19536,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19342,334 +19605,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19677,11 +19940,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19690,30 +19953,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19721,11 +19984,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19735,11 +19998,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19748,66 +20011,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19815,38 +20078,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19857,13 +20120,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19906,8 +20169,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19918,7 +20181,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19946,56 +20209,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20003,26 +20266,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20030,23 +20293,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20055,129 +20318,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20185,111 +20447,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20319,61 +20581,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20381,7 +20644,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20389,42 +20652,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20432,31 +20695,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20471,186 +20734,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20664,38 +20927,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20704,44 +20967,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20749,27 +21012,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20777,7 +21040,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20785,13 +21048,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20800,113 +21063,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20914,110 +21177,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21025,12 +21288,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21043,213 +21306,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21257,38 +21520,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21298,149 +21561,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21448,143 +21711,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21592,78 +21856,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21704,10 +21968,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21759,11 +22023,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21799,7 +22063,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21810,8 +22074,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21826,23 +22090,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21853,7 +22118,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22067,9 +22332,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22077,46 +22342,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22124,92 +22390,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22231,28 +22496,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22261,7 +22525,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22272,7 +22536,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22282,50 +22546,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22333,137 +22597,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22471,31 +22744,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22509,45 +22782,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22555,68 +22833,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22624,14 +22902,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22644,8 +22922,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22689,7 +22967,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30168,14 +30446,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30195,40 +30473,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30236,37 +30518,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30274,7 +30556,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30284,79 +30566,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30364,7 +30644,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30376,39 +30656,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30417,11 +30697,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30429,51 +30709,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30481,55 +30761,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30538,11 +30818,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30822,10 +31102,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32684,1532 +32960,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40201,7 +38951,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40589,226 +39339,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47254,9 +46123,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47310,7 +46179,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51906,6 +50775,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" diff --git a/weblate/zh_CN.po b/weblate/zh_CN.po index 5c1c806679..97d1e32287 100644 --- a/weblate/zh_CN.po +++ b/weblate/zh_CN.po @@ -25,7 +25,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-06-10 15:37+0000\n" "Last-Translator: bladesero <872461916@qq.com>\n" "Language-Team: Chinese (Simplified) ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3715,109 +3720,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3825,55 +3830,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3881,57 +3886,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3941,17 +3946,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3959,7 +3964,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3967,55 +3972,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "粒子" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -4023,24 +4028,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "导出" @@ -6791,7 +6796,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6814,7 +6819,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6825,8 +6830,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6848,7 +6853,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6912,27 +6917,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6940,17 +6945,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6960,54 +6965,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -7016,7 +7021,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -7025,18 +7030,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -7044,7 +7049,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -7052,14 +7057,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -7069,60 +7074,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -7132,11 +7137,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -7144,7 +7149,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -7152,15 +7157,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -7169,38 +7174,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -7209,20 +7214,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -7230,15 +7235,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7387,7 +7392,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7427,7 +7432,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7471,7 +7476,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7495,7 +7500,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7531,7 +7536,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7551,14 +7556,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7568,11 +7573,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7580,7 +7585,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7594,7 +7599,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7609,7 +7614,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7733,7 +7738,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7775,8 +7780,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7810,7 +7815,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7836,19 +7841,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7873,7 +7878,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7896,7 +7901,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7914,7 +7919,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7931,8 +7936,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7967,7 +7972,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -8138,7 +8143,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -8148,25 +8153,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -8189,162 +8194,162 @@ msgstr "" "该指南提供了从 Unity 用户的角度所作的概览,并旨在帮助您将现有的Unity体验迁移至" "Godot的世界里。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "不同" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "许可证" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "专有，封闭，有收入上限和使用限制的免费许可证" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "MIT许可证，免费，完全开源，没有任何限制" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "OS (编辑器)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "Windows, macOS, Linux (非正式的，不被支持的)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "OS (导出)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "移动端: Android, iOS, Windows Phone, Tizen," -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "游戏主机: PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "桌面端: Windows, X11, macOS" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "移动端: Android, iOS," -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "网页: WebAssembly" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "场景系统" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "组件/场景 (游戏物体 > 组件)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "预制体" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" ":ref:`场景树和节点`，允许场景被嵌套或继承其他场景" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "第三方工具" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "Visual Studio 或 VS Code" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr ":ref:`可使用外部编辑器 `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr ":ref:`用于导出安卓平台的 Android SDK `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "杀手级的功能" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "庞大的社区" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "大型的素材商店" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "场景系统" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr ":ref:`动画管线 `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr ":ref:`易于书写的着色器 `" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "在设备上排错" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "编辑器" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " @@ -8353,26 +8358,27 @@ msgstr "" "Godot引擎提供了一个功能丰富的编辑器，可让您构建您的游戏。以下的图片展示了带有" "表示常用功能的色彩块的编辑器。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "请注意，Godot编辑器允许您任意将各个面板停靠在场景编辑器的一侧。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#, fuzzy msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" "虽然这两个编辑器看上去相同，但是在外表之下有着许多的不同。两者都允许你使用文" "件系统来组织项目，但是Godot的方法更简单，只需要一个非常小的文本格式文件，而不" "需要元数据。所有这些都使得 Godot 对VCS系统（如 Git ， Subversion 或 " "Mercurial ）更友好。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8382,13 +8388,14 @@ msgstr "" "虽然Godot的场景面板和Unity的Hierarchy面板很相似，但是因为每个节点都有特殊的功" "能，Godot的用法更具有视觉描述性。换句话说，看一眼就能理解一个特定场景的功能。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 +#, fuzzy msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" "Godot 的 Inspector 面板更为简单，且它的设计只为显示属性服务。得益于此，对象可" @@ -8396,7 +8403,7 @@ msgstr "" "视化地为任何这些属性制作动画，所以可以在不使用代码的情况下实时改变颜色，纹" "理，枚举甚至是实时链接资源。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8407,110 +8414,118 @@ msgstr "" "目是在独立窗口中运行的，它们不会在编辑器中执行(但是树和对象仍然可以在调试窗口" "中查看)。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 +#, fuzzy msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" "这种方法的缺点就是运行中的游戏不能从其他角度观察(尽管未来可能会得到支持，并在" "运行中的游戏里显示碰撞体 gizmo也有可能)，但是作为交换有几个优点：" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 #, fuzzy msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." +"project, close the project, and then reload the previous state)." msgstr "" "运行项目与关闭它会非常快( Unity 必须保存，再运行项目，关闭项目，然后重载之前" "的状态)。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 +#: ../../docs/getting_started/editor/unity_to_godot.rst:80 +#, fuzzy msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." msgstr "" "实时编辑更加有用，因为对编辑器做的更改会立即在游戏中生效，并且在游戏关闭时不" "会丢失(也不必同步)。这提供了出色的工作流程，比如在你运行的时候创建关卡。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +#, fuzzy +msgid "The editor is more stable because the game runs in a separate process." msgstr "编辑器更加稳定，因为游戏运行在一个单独的进程中。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#, fuzzy msgid "" "Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." msgstr "" "最后，顶部的工具条包含了一个远程排错的菜单。这些选项让在设备上的部署变得简单" "(连接到手机，平板或者是支持HTML5的浏览器)，并可以在游戏导出之后排错/实时编" "辑。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 msgid "The scene system" msgstr "场景系统" -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#, fuzzy msgid "" -"This is the most important difference between Unity and Godot, and actually " +"This is the most important difference between Unity and Godot and, actually, " "the favourite feature of most Godot users." msgstr "" "这是Unity和Godot间最重要的不同点，实际上也是大多数 Godot 用户最喜爱的特性。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#, fuzzy msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." msgstr "" "Unity的场景系统包含了一个将所有需要的素材嵌入到其中的场景，并通过设置组件和脚" "本将它们链接在一起。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +#, fuzzy msgid "" "Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." msgstr "" "Godot 的场景系统与其不同：它实际上包含一个由节点组成的树。每一个节点都有它的" "用途：精灵，网格，灯光。。。基本上，这与Unity场景系统类似。但是，每个节点可以" "有多个子节点，这使得每个节点都成为主场景的子场景。这意味着你可以用不同的场景" "组成一个完整的场景，存储在不同的文件中。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:80 +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "例如，一个平台游戏的关卡。你可以用多个元素来组合它：" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "砖块" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "金币" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "玩家" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "敌人" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#, fuzzy msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" "在Unity中，你可以将所有 GameObjects 放入场景中：玩家，敌人的多个实例，组成关" @@ -8518,18 +8533,18 @@ msgstr "" "到每个元素以将它们链接起来并添加关卡中的逻辑：例如，你应该会为场景的所有元素" "各添加一个BoxCollider2D，以便它们可以发生碰撞。这个原则在 Godot中是不同的。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" "在Godot中，你要把整个场景分成3个独立的小场景，然后你将在主场景中实例化它们。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "**首先，一个只有玩家的场景。**" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " @@ -8538,11 +8553,11 @@ msgstr "" "把玩家视为一个在其他关卡中可重用的元素。它通常由一个节点组成：一个精灵动画节" "点，它包含可生成各种动画的精灵纹理(例如，步行动画)" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "**其次，一个敌人场景。**" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " @@ -8551,25 +8566,26 @@ msgstr "" "敌人也是其他关卡的可重用元素。它与Player节点几乎相同 - 唯一的区别是 " "AnimatedSprite 所使用的脚本（主要是管理AI的）和精灵纹理。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "**最后，关卡场景。**" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#, fuzzy msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" "它由砖块(用于平台)，金币(供玩家抓取)和一定数量的前一个敌人场景的实例组成。这" "些将是不同的，独立的敌人，其行为和外观将与“敌人”场景中定义的相同。然后将每个" "实例视为关卡场景树中的节点。当然，你可以为每个敌人节点设置不同的属性(例如改变" "它的颜色)。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8583,7 +8599,7 @@ msgstr "" "者“2D节点”（所有2D相关节点的根类型），“空间”（所有3D相关节点的根类型）或“控" "制”（所有GUI相关节点的根类型）。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8597,7 +8613,7 @@ msgstr "" "有碰撞属性的新特定节点的* 子节点 *。Godot具有各种碰撞类型节点，具体取决于使用" "情况（请参阅： ref：`Physics introduction `。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " @@ -8606,21 +8622,23 @@ msgstr "" "问题：这个系统的优点是什么？这个系统不会增加场景树的深度吗？此外，Unity允许通" "过将 GameObjects 放置在空的 GameObjects 中来组织他们。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#, fuzzy msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" "首先，这个系统更接近于众所周知的面向对象的标准： Godot 提供了许多不清楚“游戏" "对象”的节点，但它们为子节点提供了自己本身的功能：这就是继承。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 +#, fuzzy msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" @@ -8629,18 +8647,19 @@ msgstr "" "的更好的解决方案，因为您可以将任何子树作为任何节点的子节点。除了可视化组织" "外，将多个节点放入Unity中的空 GameObject 中并不能提供相同的可能性。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 +#, fuzzy msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "这些是你需要记住的最重要的概念：“节点”，“父节点”和“子节点”。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "项目组织" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " @@ -8649,10 +8668,11 @@ msgstr "" "我们之前观察到，没有完美的设置项目体系结构的解决方案。 任何解决方案都适用于 " "Unity 和 Godot ，所以这一点不太重要。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#, fuzzy msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" @@ -8660,22 +8680,23 @@ msgstr "" "Assets文件夹，其中包含各种文件夹，每种资源类型各一个：音频，图形，模型，材" "质，脚本，场景等。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 +#, fuzzy msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" "如前所述，Godot场景系统允许将场景切割成更小的场景。 由于每个场景和子场景实际" "上都是项目中的一个场景文件，因此我们建议用不同的方法组织你的项目。 这个wiki为" "此提供了一个页面：：ref：`doc_project_organization`。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "我的预制体在哪里？" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8685,56 +8706,58 @@ msgstr "" "Unity 提供的预制体的概念是场景的“模板”元素。 它是可重复使用的，并且场景中存在" "的预制体的每个实例都有其自己的存在，但它们都具有与预制体所定义的相同的属性。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 +#, fuzzy msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" "Godot不提供这样的预制体，但它的功能由它的场景系统所弥补：正如我们所看到的，场" "景系统由一棵树组成。 Godot 允许你将场景的一个子树保存为自己的场景，并保存在自" "己的文件中。这个新场景可以随意多次实例化。您对这个新的独立场景所做的任何更改" "都将应用于其实例。但是，对实例所做的任何更改都不会对“模板”场景产生任何影响。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 +#, fuzzy msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" "确切地说，你可以在 Inspector 面板中修改实例的参数。但是，组成此实例的节点已锁" "定，如果有必要请右键单击“场景”树中的实例并在菜单中选择“可编辑的子项”，即可以" "解锁它们。 您不需要这样做来为此节点添加新的子节点，但请记住，这些新子节点将属" "于该实例，而不是“模板”场景。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "术语对应" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "GameObject - >节点 添加组件 - >继承 预制体 - >外化分支" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "脚本：GDScript ，C＃ 和 Visual Script" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "设计" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." @@ -8742,16 +8765,17 @@ msgstr "" "如你所知，Unity 支持 C#。C# 从与 Visual Studio 集成中受益和其他的功能中受益，" "例如静态类型。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 #, fuzzy msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" "Godot提供了自己的脚本语言：ref：`GDScript ` ，并且支持：ref：" "`Visual Script `和：ref：`C＃" @@ -8760,10 +8784,11 @@ msgstr "" "pages。GDScript 非常依赖于Godot API，但它的确很容易学习：一个有经验的程序员一" "个晚上就能学会，一个真正的初学者也只需一个星期。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 +#, fuzzy msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" @@ -8771,47 +8796,50 @@ msgstr "" "加一个行为：例如，你可以添加一个脚本，以便它对玩家的控制作出反应，而另一个脚" "本控制其特定的游戏逻辑。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 +#, fuzzy msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" "在Godot中，每个节点只能附加一个脚本。您可以使用外部 GDScript 文件，也可以直接" "将其包含在节点中。如果您需要将更多脚本附加到一个节点上，那么您可以考虑这两种" "解决方案，具体取决于您的场景以及您想实现的目标：" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" "在目标节点和其当前父节点之间添加一个新节点，然后向该新节点添加一个脚本。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "或者，您可以将您的目标节点分成多个子节点并为其中的每一个添加一个脚本。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 +#, fuzzy msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" "正如你所看到的，把场景树变成一团糟可能很容易。 这就是拥有一个真正的反射的重要" "性，并且考虑把一个复杂的场景分成多个小的分支。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "连接：组和信号" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 +#, fuzzy msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" @@ -8819,23 +8847,23 @@ msgstr "" "的）。但还有：你也可以将它们放在一个组中，并调用一个在该组中包含的所有节点上" "的函数！解释如下：ref：`this page `。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 +#, fuzzy msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" "但还有！ 某些节点在某些操作发生时会抛出信号。您可以连接这些信号以便在触发的时" "候来调用特定的函数。请注意，您可以定义自己的信号并随时发送。这个功能记录在这" "里`_。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "在 Godot 中使用 C++" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 #, fuzzy msgid "" "For your information, Godot also allows you to develop your project directly " @@ -8847,7 +8875,7 @@ msgstr "" "Unity 。 例如，您可以将 Godot 引擎的编辑器视为使用 Godot API 用C ++编写的“游" "戏”。" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8875,8 +8903,9 @@ msgid "Path" msgstr "路径" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 +#, fuzzy msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8920,33 +8949,34 @@ msgstr "例如，用于导出游戏的完整命令（如下所述）可能看上 msgid "Creating a project" msgstr "创建一个项目" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 #, fuzzy msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" "从命令行创建一个项目非常简单，只需将shell导航到所需的位置，并创建 project." "godot 文件，即使其为空的。" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "运行编辑器" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 +#, fuzzy msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" "运行编辑器是通过用``-e``标志执行 godot 来完成的。 这必须在项目目录或子目录内" "完成，否则该命令将被忽略并显示项目管理器。" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." @@ -8954,40 +8984,41 @@ msgstr "" "如果已经创建并保存了一个场景，它可以通过运行把场景作为参数的同样的代码来进行" "编辑。" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "擦除一个场景" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 +#, fuzzy msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" "Godot对你的文件系统非常友好，不会创建额外的元数据文件，只需使用``rm``来擦除文" "件。 确保没有对该场景的引用，否则在打开时会抛出错误。" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "运行游戏" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "要运行游戏，只需在项目目录或子目录中执行 Godot 即可。" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "当需要测试特定的场景时，将该场景传递给命令行。" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "调试" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " @@ -8996,7 +9027,7 @@ msgstr "" "捕捉命令行中的错误可能是一项艰巨的任务，因为它们一闪而过。 为此，通过添加``-" "d``来提供命令行调试器。 它适用于运行游戏或简单的场景。" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " @@ -9005,7 +9036,7 @@ msgstr "" "从命令行导出项目也被支持。 这对建构持续集成特别有用。 headless的Godot版本（服" "务器版本，无视频）对此非常理想。" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 #, fuzzy msgid "" "The platform names recognized by the ``--export`` switch are the same as " @@ -9017,7 +9048,7 @@ msgstr "" "获取受支持平台的列表，只需尝试导出到未识别的平台，然后就会显示配置支持的完整" "平台列表。" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." @@ -9025,11 +9056,11 @@ msgstr "" "要导出游戏的调试版本，请使用“--export-debug”开关而不是“--export”。 他们的参数" "和用法是相同的。" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "运行脚本" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 #, fuzzy msgid "" "It is possible to run a simple .gd script from the command line. This " @@ -9039,19 +9070,19 @@ msgstr "" "可以从命令行运行简单的 .gd 脚本。 此功能在非常大的项目中特别有用，可用于批量" "转换资产或自定义导入/导出。" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "该脚本必须继承了场景树或主循环。" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "下面是一个简单的示例，说明它是如何工作的：" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "以及如何运行它:" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -12367,10 +12398,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -13423,7 +13454,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -14083,6 +14114,262 @@ msgid "" msgstr "" "如果一个文件夹不应该导入Godot，那么可以使用 .gdignore 文件进行异常处理。" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +#, fuzzy +msgid "Godot-Blender-Exporter" +msgstr "Godot 场景导入器" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +#, fuzzy +msgid "Build Pipeline Integration" +msgstr "构建配置：" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "材质" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +#, fuzzy +msgid "Export of Blender materials" +msgstr "导出模板" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "灯光" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Godot没有任何使用限制" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +#, fuzzy +msgid "Body Type" +msgstr "根类型" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +#, fuzzy +msgid "There are the following caveats:" +msgstr "并填入下面的内容：" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "资产工作流" @@ -15105,10 +15392,29 @@ msgstr "" "exporter>`__，可以更好地导出场景。" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 +#, fuzzy +msgid "Exporting ESCN files from Blender" +msgstr "从 Blender 导出 DAE 文件" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 +msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 msgid "Import workflows" msgstr "导入工作流" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" @@ -15116,75 +15422,75 @@ msgstr "" "Godot 场景导入器支持对数据的导入方式进行不同的工作流。 根据许多选项，可以通过" "以下方式导入场景：" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "外部材质（默认）：每种材料保存到文件资源的位置。 可以对它们进行修改。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "外部网格：每个网格被保存到不同的文件。 许多用户更喜欢直接处理网格。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "外部动画：允许修改已保存的动画并在源更改时进行合并。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "外部场景：将导入的场景的根节点分别保存为单独的场景。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "单场景：一个场景文件，内置所有内容。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "由于不同的开发人员有不同的需求, 这个导入过程是高度可定制的。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "导入选项" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "导入器有几种选项，这将在下面讨论：" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "节点：" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "根类型" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "默认情况下，导入场景中根节点的类型为“Spatial”，但可以修改。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "根名称" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "允许为生成的根节点设置特定的名称。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "自定义脚本" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " @@ -15193,12 +15499,12 @@ msgstr "" "可以提供导入后处理整个场景的特殊脚本。 这对于后期处理，更换材质，用几何体做些" "有趣的事情等非常有用。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 #, fuzzy msgid "Create a script that like this:" msgstr "创建脚本基本如下所示:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " @@ -15207,14 +15513,14 @@ msgstr "" "导入后函数将导入的场景作为参数（参数实际上是场景的根节点）。 必须返回将最终使" "用的场景。 它可以是不同的。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "存储" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " @@ -15223,27 +15529,23 @@ msgstr "" "默认情况下，Godot导入一个单独的场景。 此选项允许指定根节点下方的节点将分别为" "单独的场景并实例化为导入的节点。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "当然，在其他地方手动实例导入的场景也是可以的。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "材质" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "位置" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "Godot 支持网格或节点中的材料。 默认情况下，材料将放置在每个节点上。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -15254,17 +15556,17 @@ msgstr "" "进行编辑。 这是因为大多数 3D 数字创作软件没有与 Godot 中的材料相同的材料选" "项。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "当材料内置时，每当源场景被修改并重新导入时，它们都会丢失。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "保留重新导入" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " @@ -15273,90 +15575,90 @@ msgstr "" "一旦材质被编辑为使用Godot功能，导入器将保留编辑过的材质并忽略来自源场景的材" "质。 该选项仅在材质保存为文件时才存在。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "压缩" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "使网格在网格的多个方面使用较少的精确数字以节省空间。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "这些是:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "变换矩阵（位置，旋转和缩放）：32位浮点数到16位有符号整数。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "顶点:32 位浮点数到16位有符号整数。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "法线:32 位浮点数到32位无符号整数。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "切线:32 位浮点数到32位无符号整数。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "顶点色:32 位浮点数到32位无符号整数。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "UV:32 位浮点数到32位无符号整数。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "UV2:32 位浮点数到32位无符号整数。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "顶点权重:32 位浮点数到32位无符号整数。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "骨架骨骼:32 位浮点数到16位无符号整数。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "数组索引: 基于具体有多少元素的32位或16位无符号整数。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "附加信息：" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "UV2 = 用于细节纹理和烘焙光照纹理的第二个 UV 通道。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." @@ -15364,7 +15666,7 @@ msgstr "" "数组索引 = 一个数字数组, 它为上面数组的每个元素编号;即, 他们的顶点和法线的数" "量。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -15376,15 +15678,15 @@ msgstr "" "常大或导入了多个覆盖大面积的网格，则压缩此网格的导入可能会导致几何图形或顶点" "间的间隙不在他们应在的位置。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "网格" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "计算的切线" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -15394,7 +15696,7 @@ msgstr "" "如果要使用正常贴图的纹理，网格需要有切线阵列。 此选项可确保在源场景中不存在时" "生成这些阵列。 Godot 使用 Mikktspace 来做这件事，但最好让它们在导出器中生成。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " @@ -15403,27 +15705,27 @@ msgstr "" "网格可以存储在单独的文件（资源）中，而不是内置的。 除非有人想直接用它们建立对" "象，否则这没有多少实际用途。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "此选项用于帮助那些喜欢直接使用网格而不是场景的人。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "外部文件" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "生成的网格和材质可以选择存储在具有场景名称的子目录中。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "动画选项" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -15434,15 +15736,15 @@ msgstr "" "文件中生成许多动画。 其他的，如3DS Max 或 Maya，需要将许多动画放入同一时间" "线，或者最糟糕的情况是将每个动画放在单独的文件中。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "默认情况下启用动画导入。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "帧数" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -15452,11 +15754,11 @@ msgstr "" "大多数 3D 导出格式以秒为单位存储的动画时间线，而不是帧。 为了确保尽可能忠实地" "导入动画，请指定用于编辑它们的每秒帧数。 未能这样做可能会导致极小的抖动。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "过滤器脚本" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " @@ -15464,7 +15766,7 @@ msgid "" msgstr "" "可以用特殊的语法指定过滤器脚本, 以决定哪些轨道应保留动画。(@TODO 这需要文档)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " @@ -15473,11 +15775,11 @@ msgstr "" "默认情况下，动画保存为内置。 可以将它们保存到文件中。 这允许向动画添加自定义" "轨道并在重新导入后保留它们。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "优化" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " @@ -15486,11 +15788,11 @@ msgstr "" "导入动画时，会运行优化程序，从而大大减少动画的大小。 一般情况下，除非您怀疑动" "画可能因启用而被破坏，否则应始终启用此功能。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "片段" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 #, fuzzy msgid "" "It is possible to specify multiple animations from a single timeline as " @@ -15500,11 +15802,11 @@ msgstr "" "可以将单个时间线中的多个动画指定为片段。只需指定从哪帧到哪帧（当然，不要忘记" "指定上面的FPS选项）。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "场景继承" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 #, fuzzy msgid "" "In many cases, it may be desired to do modifications to the imported scene. " @@ -15516,7 +15818,7 @@ msgstr "" "果源资源发生变化（从3D建模应用程序重新导出源.dae，.gltf，.obj文件），Godot将" "重新导入整个场景。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 #, fuzzy msgid "" "It is possible, however, to do local modifications by using *Scene " @@ -15526,49 +15828,49 @@ msgstr "" "但是，可以使用* Scene Inheritance *进行本地修改。 试着打开导入的场景，会出现" "下面的对话框：" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "在继承场景中，修改的唯一限制是：" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "无法删除节点 (但可以在任何位置添加)。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "子资源无法编辑（如上所述它们将保存在外部）" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "除了这些, 一切都是允许的!" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "导入提示" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "很多时候, 在编辑场景时, 导出后需要完成一些常见的任务:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "向对象添加碰撞检测:" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "将对象设置为导航网格" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "删除游戏引擎中未使用的节点 (如用于建模的特定光源)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " @@ -15577,11 +15879,11 @@ msgstr "" "为了简化这一工作流程，Godot 提供了一些后缀，可以添加到3D建模软件中的对象名称" "中。 当输入时，Godot会自动检测它们并执行操作：" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "删除节点 (-noimp)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 #, fuzzy msgid "" "Node names that have this suffix will be removed at import time, no matter " @@ -15590,11 +15892,11 @@ msgstr "" "具有此后缀的节点名称将在导入时被删除, 不管它们的类型是什么。它们不会出现在导" "入的场景中。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "创建碰撞体 (-colonly,-convcolonly)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." @@ -15602,14 +15904,14 @@ msgstr "" "选项“-col”只能用于 Mesh 节点。 如果检测到，则会添加子静态碰撞节点，使用与网格" "相同的几何体。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" "然而，通常是可视几何体对于碰撞来说太复杂或太不平滑，这最终不能很好地工作。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " @@ -15618,7 +15920,7 @@ msgstr "" "为了解决这个问题, \"-colonly\" 修饰符存在, 它将在导入时删除网格, 并创建一个: " "ref: \"class_staticbody\" 碰撞体。这有助于将可视的网格和实际碰撞体分开。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." @@ -15626,7 +15928,7 @@ msgstr "" "选项“-convcolonly”将创建：ref：`class_convexpolygonshape`而不是：ref：" "`class_concavepolygonshape`。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -15637,23 +15939,23 @@ msgstr "" "撞节点的：ref：`class_staticbody`作为孩子。 Collision节点将有一个预定义的形" "状，具体取决于Blender的空物体类型：" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "单箭头将创建: ref: ' class_rayshape '" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "方块将创建：ref：`class_boxshape`" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "图像将创建: ref: ' class_planeshape '" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "球体 (和其他未列出的) 将创建: ref: ' class_sphereshape '" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " @@ -15662,21 +15964,21 @@ msgstr "" "为了提高Blender编辑器的可见性，用户可以在碰撞体上设置“X-Ray”选项，并在用户首" "选项/主题/ 3D视图/空物体中为它们设置不同的颜色。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "创建navigatopm（-navmesh）" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "具有此后缀的网格节点将被转换为导航网格。原始网格节点将被删除。" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "刚体 (-rigid)" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "从这个网格中创建一个刚体。" @@ -17650,7 +17952,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -17675,8 +17977,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -17711,7 +18013,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -17756,16 +18058,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17861,7 +18163,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17990,7 +18292,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -18130,7 +18432,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -18145,7 +18447,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -18245,44 +18547,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -18291,17 +18593,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -18313,7 +18615,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -18325,25 +18627,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -18351,61 +18653,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -18416,29 +18718,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "工具（tools）" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -18555,9 +18857,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -18566,8 +18868,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -18806,8 +19108,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -19085,9 +19387,10 @@ msgid "Generated geometry" msgstr "生成的几何体" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 +#, fuzzy msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -19150,7 +19453,7 @@ msgstr "" "用像素作业的参考。" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "环境" @@ -19311,8 +19614,9 @@ msgstr "" "否则不会显示任何内容。 相机可以在正交或透视投影中工作：" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 +#, fuzzy msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -19352,10 +19656,6 @@ msgid "" "will take its place." msgstr "如果活动摄像机离开场景树，则按树形顺序排列的第一台摄像机将取代它。" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "灯光" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -19868,9 +20168,10 @@ msgid "3D performance and limitations" msgstr "3D性能和局限性" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 +#, fuzzy msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" "戈多遵循平衡的表现哲学。 在性能方面，总是存在权衡，其中包括可用性和灵活性间的" @@ -19879,9 +20180,9 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -19924,6 +20225,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -20247,8 +20549,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -20262,14 +20564,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -20301,67 +20603,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -20370,334 +20672,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -20705,11 +21007,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -20718,30 +21020,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -20749,11 +21051,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -20763,11 +21065,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "深度" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -20776,66 +21078,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -20843,38 +21145,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -20885,13 +21187,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -20934,8 +21236,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -20946,7 +21248,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -20974,56 +21276,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -21031,26 +21333,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -21058,23 +21360,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -21083,129 +21385,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -21213,111 +21514,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -21347,61 +21648,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -21409,7 +21711,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -21417,42 +21719,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -21460,31 +21762,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -21499,186 +21801,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -21692,38 +21994,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -21732,44 +22034,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -21777,27 +22079,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -21805,7 +22107,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -21813,13 +22115,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -21828,113 +22130,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -21942,110 +22244,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -22053,12 +22355,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -22071,213 +22373,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -22285,38 +22587,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -22326,149 +22628,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -22476,143 +22778,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -22620,78 +22923,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -22732,10 +23035,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -22787,11 +23090,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -22827,7 +23130,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -22838,8 +23141,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -22854,23 +23157,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -22881,7 +23185,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -23095,9 +23399,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -23105,46 +23409,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -23152,92 +23457,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -23259,28 +23563,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -23289,7 +23592,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -23300,7 +23603,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -23310,50 +23613,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -23361,137 +23664,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -23499,31 +23811,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -23537,45 +23849,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -23583,68 +23900,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -23652,14 +23969,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -23672,8 +23989,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -23717,7 +24034,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -31209,14 +31526,14 @@ msgid "Audio" msgstr "音频" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -31236,40 +31553,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -31277,37 +31598,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -31315,7 +31636,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -31325,79 +31646,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -31405,7 +31724,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -31417,39 +31736,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -31458,11 +31777,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -31470,51 +31789,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -31522,55 +31841,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -31579,11 +31898,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -31863,10 +32182,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -33725,1532 +34040,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -41347,7 +40136,7 @@ msgid "Or alternatively, set it via function:" msgstr "或者, 通过函数设置:" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "输入" @@ -41769,157 +40558,181 @@ msgstr "视区" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" -"Godot有一个很小但有用的功能称为视区。顾名思义, 视区是绘制世界的长方形。他们有" -"三主要用途, 但能灵活地适应更多目的。所有这一切都是通过:ref:`Viewport " -"` 节点完成的。" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" -msgstr "上面提到的三个主要用途如下：" - -#: ../../docs/tutorials/viewports/viewports.rst:18 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -"** 场景的根 **: 场景的根节点始终是视区。这用来显示用户创建的场景的内容。(通过" -"阅读以前的教程您应该知晓这一点!）" -#: ../../docs/tutorials/viewports/viewports.rst:21 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -"** 子视区 **: 当视区为 :ref:`Control ` 的子节点时, 子视区就会" -"被创建出来。" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" -"** 渲染目标 **: 视区可以设置为 \"RenderTarget\" （渲染目标）模式。这意味着视" -"区不是直接可见的, 但它的内容可以通过:ref:`Texture `来访问。" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:40 +#, fuzzy +msgid "" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" "视区还负责向其所有子节点传递关于适当调整和缩放的输入事件。根视区和子视区都会" "自动执行此任务, 但作渲染目标用途时不会。因此, 在需要的时候用户必须手动通过:" "ref:`Viewport.input() `来实现（传递输入事件）。" -#: ../../docs/tutorials/viewports/viewports.rst:37 +#: ../../docs/tutorials/viewports/viewports.rst:48 +#, fuzzy +msgid "" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "有关事件（event）本身的详细信息, 请查看 :ref:`doc_inputevent` 教程。" + +#: ../../docs/tutorials/viewports/viewports.rst:51 msgid "Listener" msgstr "侦听者" -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:53 +#, fuzzy msgid "" "Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" "Godot支持3D声音 (2D和3D节点皆可), 更多关于这点的信息可以在另一个教程中找到 " "(有朝一日......)。要使此类声音能被侦听到, 视区需要作为侦听器（listener） (2D" "或3D) 启用。如果您使用自定义视区来显示您的世界, 请不要忘记启用此项!" -#: ../../docs/tutorials/viewports/viewports.rst:46 +#: ../../docs/tutorials/viewports/viewports.rst:60 msgid "Cameras (2D & 3D)" msgstr "摄像机 (2D和3D)" -#: ../../docs/tutorials/viewports/viewports.rst:48 +#: ../../docs/tutorials/viewports/viewports.rst:62 +#, fuzzy msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" "当使用2D或3D:ref:`Camera ` / :ref:`Camera2D `" "类 时, 摄像机将始终显示其最近的父视区 (向根方向)。例如, 在以下层次结构中:" -#: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "Viewport" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "Camera" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "摄像机将显示其父视区, 但在下面的层次结构中:" - -#: ../../docs/tutorials/viewports/viewports.rst:63 +#: ../../docs/tutorials/viewports/viewports.rst:69 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." -msgstr "它不会 (或者显示其根视区如果这是一个子场景的话)。" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:75 +#, fuzzy msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" msgstr "" "每个视区只能有一个激活的摄像机, 因此, 如果有多个摄像机时, 请确保你需要的那个" "摄像机的“current”属性被设置上，或者通过调用以下语句来使其成为当前摄像机:" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "缩放和拉伸" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -"视区有一个 \"rect\" 属性。通常不使用 X 和 Y (只有根视区使用它们), 而是用“宽" -"度”和“高度”表示视区的大小 (以像素为单位)。对于“子视区”而言, 这些值是由其某个" -"父控件的对应属性所覆写的, 但对于“渲染目标”而言, 这两个属性会确定它的分辨率。" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 +#, fuzzy msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "通过调用以下语句，还可以缩放2D内容, 使其忽略rect中已指定的视区分辨率:" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." -msgstr "“根视区”用这些语句设定项目设置中的拉伸选项。" +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" +msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "世界类（World）" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 +#, fuzzy msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" "对于3D, 视区将包含一个:ref:`World `类。这基本上就是一个把物理和" "渲染联系在一起的宇宙世界。基于空间概念的节点将使用最接近的视区的世界进行注" @@ -41929,119 +40742,217 @@ msgstr "" "视区交互。这在某些情形下尤为有用, 例如, 您可能希望在游戏中以三维视角来看的上" "方显示一个单独的字符（比如星际争霸）。" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 +#, fuzzy msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" "某些时刻您希望创建用来显示单个对象的viewport，且不想创建World, 为帮助您实现按" "这样的需求视区提供了选项来自行指定World。当您希望在2D世界中实例化3D角色或对象" "时, 这个选项很有用。" -#: ../../docs/tutorials/viewports/viewports.rst:114 +#: ../../docs/tutorials/viewports/viewports.rst:121 +#, fuzzy msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" "对于2D, 每个Viewport始终包含其自己的:ref:`World2D `。在大多数" "情况下这是足够的, 但如果需要共享World, 那么手动调用视区的 API 来实现也是可行" "的。" -#: ../../docs/tutorials/viewports/viewports.rst:119 +#: ../../docs/tutorials/viewports/viewports.rst:125 +msgid "" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:128 msgid "Capture" msgstr "截图" -#: ../../docs/tutorials/viewports/viewports.rst:121 +#: ../../docs/tutorials/viewports/viewports.rst:130 +#, fuzzy msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" msgstr "" "可以通过查询得到视区内容的一份截图。对于”根视区“, 这实际上是一个屏幕截图。这" "是通过以下 API 完成的:" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:147 +#, fuzzy msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" msgstr "" "但是要注意, 如果您在 _ready() 或视区初始化的第一帧中使用上述方法, 则会得到一" "个空的texture, 因为没有任何纹理可供获取。您可以使用如下方法来处理这种情况（见" "例子）:" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -"如果你发现返回的图像为空, 则说明捕获截图的行为仍未发生, 请稍微多等一会, 因为" -"这个 API 是异步的。" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" -msgstr "子视区" +#: ../../docs/tutorials/viewports/viewports.rst:163 +#, fuzzy +msgid "Viewport Container" +msgstr "ViewportContainer" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 +#, fuzzy msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" "如果视区是:ref:`ViewportContainer `的子节点, 那么它" "将变为活动状态并显示其内部的任何内容。层级关系布局类似如下:" -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "ViewportContainer" - -#: ../../docs/tutorials/viewports/viewports.rst:161 +#: ../../docs/tutorials/viewports/viewports.rst:170 +#, fuzzy msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" "如果在视区容器（Viewport Container）中将拉伸设置为 true, 则视区（Viewport）将" "完全覆盖其父控件的区域。但您必须设置Viewport的”Size“属性才能获取合适的视区部" "分。并且注意视区容器的尺寸不能小于视区本身的尺寸。" -#: ../../docs/tutorials/viewports/viewports.rst:168 +#: ../../docs/tutorials/viewports/viewports.rst:177 +msgid "" +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:186 +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 +msgid "" +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 msgid "Render target" msgstr "渲染目标" -#: ../../docs/tutorials/viewports/viewports.rst:170 +#: ../../docs/tutorials/viewports/viewports.rst:214 +#, fuzzy msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" msgstr "" "为了启用”渲染目标“模式, 请勾选视区的 \"render target\" 属性，切换为 enable。" "请注意, 该模式下任何视区内部的东西都不会在场景编辑器中看到。若要显示内容, 方" "法与之前一样。可以通过使用代码 来请求到需要的内容（如下）:" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:224 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +#, fuzzy +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." msgstr "" "默认情况下, 当”渲染目标“的纹理在某一帧被绘制时, ”渲染目标“会被重新渲染。如果" "是可见的, 就渲染它, 反之则不。此行为可以更改为手动渲染 (一次), 或始终渲染, 无" "论是否可见。" -#: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" -msgstr "``TODO: 审阅文档, 更改过期内容并添加更多图片。``" - -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:245 +#, fuzzy msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -48535,9 +47446,9 @@ msgstr "使用模块" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -48591,7 +47502,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -53394,6 +52305,10 @@ msgstr "容器" msgid "Godot provides also a set of common containers:" msgstr "Godot 还提供了一系列通用的容器：" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr "" @@ -58495,6 +57410,87 @@ msgid "" "`_" msgstr "" +#~ msgid "" +#~ "Godot has a small but useful feature called viewports. Viewports are, as " +#~ "the name implies, rectangles where the world is drawn. They have three " +#~ "main uses, but can flexibly adapted to a lot more. All this is done via " +#~ "the :ref:`Viewport ` node." +#~ msgstr "" +#~ "Godot有一个很小但有用的功能称为视区。顾名思义, 视区是绘制世界的长方形。他" +#~ "们有三主要用途, 但能灵活地适应更多目的。所有这一切都是通过:ref:`Viewport " +#~ "` 节点完成的。" + +#~ msgid "The main uses in question are:" +#~ msgstr "上面提到的三个主要用途如下：" + +#~ msgid "" +#~ "**Scene Root**: The root of the active scene is always a Viewport. This " +#~ "is what displays the scenes created by the user. (You should know this by " +#~ "having read previous tutorials!)" +#~ msgstr "" +#~ "** 场景的根 **: 场景的根节点始终是视区。这用来显示用户创建的场景的内容。" +#~ "(通过阅读以前的教程您应该知晓这一点!）" + +#~ msgid "" +#~ "**Sub-Viewports**: These can be created when a Viewport is a child of a :" +#~ "ref:`Control `." +#~ msgstr "" +#~ "** 子视区 **: 当视区为 :ref:`Control ` 的子节点时, 子视区就" +#~ "会被创建出来。" + +#~ msgid "" +#~ "**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " +#~ "means that the viewport is not directly visible, but its contents can be " +#~ "accessed via a :ref:`Texture `." +#~ msgstr "" +#~ "** 渲染目标 **: 视区可以设置为 \"RenderTarget\" （渲染目标）模式。这意味着" +#~ "视区不是直接可见的, 但它的内容可以通过:ref:`Texture `来访" +#~ "问。" + +#~ msgid "Viewport" +#~ msgstr "Viewport" + +#~ msgid "Camera" +#~ msgstr "Camera" + +#~ msgid "" +#~ "Camera will display on the parent viewport, but in the following one:" +#~ msgstr "摄像机将显示其父视区, 但在下面的层次结构中:" + +#~ msgid "" +#~ "It will not (or may display in the root viewport if this is a subscene)." +#~ msgstr "它不会 (或者显示其根视区如果这是一个子场景的话)。" + +#~ msgid "" +#~ "Viewports have a \"rect\" property. X and Y are often not used (only the " +#~ "root viewport uses them), while WIDTH AND HEIGHT represent the size of " +#~ "the viewport in pixels. For Sub-Viewports, these values are overridden by " +#~ "the ones from the parent control, but for render targets this sets their " +#~ "resolution." +#~ msgstr "" +#~ "视区有一个 \"rect\" 属性。通常不使用 X 和 Y (只有根视区使用它们), 而是" +#~ "用“宽度”和“高度”表示视区的大小 (以像素为单位)。对于“子视区”而言, 这些值是" +#~ "由其某个父控件的对应属性所覆写的, 但对于“渲染目标”而言, 这两个属性会确定它" +#~ "的分辨率。" + +#~ msgid "" +#~ "The root viewport uses this for the stretch options in the project " +#~ "settings." +#~ msgstr "“根视区”用这些语句设定项目设置中的拉伸选项。" + +#~ msgid "" +#~ "If the returned image is empty, capture still didn't happen, wait a " +#~ "little more, as this API is asynchronous." +#~ msgstr "" +#~ "如果你发现返回的图像为空, 则说明捕获截图的行为仍未发生, 请稍微多等一会, 因" +#~ "为这个 API 是异步的。" + +#~ msgid "Sub-viewport" +#~ msgstr "子视区" + +#~ msgid "``TODO: Review the doc, change outdated and add more images.``" +#~ msgstr "``TODO: 审阅文档, 更改过期内容并添加更多图片。``" + #~ msgid "That alone makes for an empty Godot project." #~ msgstr "这仅仅创建了一个空的 Godot 项目。" diff --git a/weblate/zh_TW.po b/weblate/zh_TW.po index 9df9846c5e..dd7778a3ed 100644 --- a/weblate/zh_TW.po +++ b/weblate/zh_TW.po @@ -10,7 +10,7 @@ msgid "" msgstr "" "Project-Id-Version: Godot Engine latest\n" "Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n" -"POT-Creation-Date: 2018-06-13 14:08+0200\n" +"POT-Creation-Date: 2018-06-18 08:58+0200\n" "PO-Revision-Date: 2018-04-29 15:59+0000\n" "Last-Translator: Matt \n" "Language-Team: Chinese (Traditional) ` node lets us draw our UI elements " "on a layer above the rest of the game, so that the information it displays " "isn't covered up by any game elements like the player or mobs." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:827 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:832 msgid "The HUD displays the following information:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:829 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:834 msgid "Score, changed by ``ScoreTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:830 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:835 msgid "A message, such as \"Game Over\" or \"Get Ready!\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:831 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:836 msgid "A \"Start\" button to begin the game." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:833 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:838 msgid "" "The basic node for UI elements is :ref:`Control `. To create " "our UI, we'll use two types of :ref:`Control ` nodes: :ref:" "`Label ` and :ref:`Button `." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:837 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 msgid "Create the following as children of the ``HUD`` node:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:839 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 msgid ":ref:`Label ` named ``ScoreLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:840 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:845 msgid ":ref:`Label ` named ``MessageLabel``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:841 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:846 msgid ":ref:`Button ` named ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:842 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:847 msgid ":ref:`Timer ` named ``MessageTimer``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:844 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:849 msgid "" "**Anchors and Margins:** ``Control`` nodes have a position and size, but " "they also have anchors and margins. Anchors define the origin - the " @@ -3356,109 +3358,109 @@ msgid "" "`doc_design_interfaces_with_the_control_nodes` for more details." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:851 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 msgid "" "Arrange the nodes as shown below. Click the \"Anchor\" button to set a " "Control node's anchor:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:856 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:861 msgid "" "You can drag the nodes to place them manually, or for more precise " "placement, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:860 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 msgid "ScoreLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:862 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 msgid "``Layout``: \"Center Top\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:863 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:876 -#: ../../docs/getting_started/step_by_step/your_first_game.rst:889 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 msgid "``Margin``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:865 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 msgid "Left: ``-25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:866 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:871 msgid "Top: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:867 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:872 msgid "Right: ``25``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:868 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 msgid "Bottom: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:870 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 msgid "Text: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:873 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 msgid "MessageLabel" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:875 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 msgid "``Layout``: \"Center\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:878 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 msgid "Left: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:879 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:884 msgid "Top: ``-150``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:880 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:885 msgid "Right: ``200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:881 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 msgid "Bottom: ``0``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:883 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 msgid "Text: ``Dodge the Creeps!``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:886 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 msgid "StartButton" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:888 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 msgid "``Layout``: \"Center Bottom\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:891 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 msgid "Left: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:892 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:897 msgid "Top: ``-200``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:893 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 msgid "Right: ``100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:894 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:899 msgid "Bottom: ``-100``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:896 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:901 msgid "Text: ``Start``" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:898 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 msgid "" "The default font for ``Control`` nodes is small and doesn't scale well. " "There is a font file included in the game assets called \"Xolonium-Regular." @@ -3466,55 +3468,55 @@ msgid "" "nodes:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:903 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:908 msgid "Under \"Custom Fonts\", choose \"New DynamicFont\"" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:907 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:912 msgid "" "Click on the \"DynamicFont\" you added, and under \"Font Data\", choose " "\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the " "font's ``Size``. A setting of ``64`` works well." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:913 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:918 msgid "Now add this script to ``HUD``:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:930 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:935 msgid "" "The ``start_game`` signal tells the ``Main`` node that the button has been " "pressed." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:953 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:958 msgid "" "This function is called when we want to display a message temporarily, such " "as \"Get Ready\". On the ``MessageTimer``, set the ``Wait Time`` to ``2`` " "and set the ``One Shot`` property to \"On\"." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:982 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:987 msgid "" "This function is called when the player loses. It will show \"Game Over\" " "for 2 seconds, then return to the title screen and show the \"Start\" button." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1000 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005 msgid "This function is called in ``Main`` whenever the score changes." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1002 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007 msgid "" "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` " "signal of ``StartButton``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1032 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1037 msgid "Connecting HUD to Main" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1039 msgid "" "Now that we're done creating the ``HUD`` scene, save it and go back to " "``Main``. Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` " @@ -3522,57 +3524,57 @@ msgid "" "like this, so make sure you didn't miss anything:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1041 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046 msgid "" "Now we need to connect the ``HUD`` functionality to our ``Main`` script. " "This requires a few additions to the ``Main`` scene:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1044 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1049 msgid "" "In the Node tab, connect the HUD's ``start_game`` signal to the " "``new_game()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052 msgid "" "In ``new_game()``, update the score display and show the \"Get Ready\" " "message:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1062 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1067 msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1074 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079 msgid "" "Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in " "sync with the changing score:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1087 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1092 msgid "" "Now you're ready to play! Click the \"Play the Project\" button. You will be " "asked to select a main scene, so choose ``Main.tscn``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1091 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1096 msgid "Finishing Up" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1093 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 msgid "" "We have now completed all the functionality for our game. Below are some " "remaining steps to add a bit more \"juice\" to improve the game experience. " "Feel free to expand the gameplay with your own ideas." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:51 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 msgid "Background" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1100 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105 msgid "" "The default gray background is not very appealing, so let's change its " "color. One way to do this is to use a :ref:`ColorRect ` " @@ -3582,17 +3584,17 @@ msgid "" "screen." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112 msgid "" "You can also add a background image, if you have one, by using a ``Sprite`` " "node." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1111 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116 msgid "Sound Effects" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1113 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 msgid "" "Sound and music can be the single most effective way to add appeal to the " "game experience. In your game assets folder, you have two sound files: " @@ -3600,7 +3602,7 @@ msgid "" "for when the player loses." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 msgid "" "Add two :ref:`AudioStreamPlayer ` nodes as children " "of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On " @@ -3608,55 +3610,55 @@ msgid "" "corresponding audio file." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1123 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1128 msgid "" "To play the music, add ``$Music.play()`` in the ``new_game()`` function and " "``$Music.stop()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1126 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1129 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134 #: ../../docs/tutorials/shading/shading_language.rst:1077 msgid "Particles" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136 msgid "" "For one last bit of visual appeal, let's add a trail effect to the player's " "movement. Choose your ``Player`` scene and add a :ref:`Particles2D " "` node named ``Trail``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1135 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140 msgid "" "There are a large number of properties to choose from when configuring " "particles. Feel free to experiment and create different effects. For the " "effect in this example, use the following settings:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1141 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 msgid "" "You also need to create a ``Material`` by clicking on ```` and then " "\"New ParticlesMaterial\". The settings for that are below:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151 msgid "" "To make the gradient for the \"Color Ramp\" setting, we want a gradient " "taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to " "0.0 (fully transparent)." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1150 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 msgid "" "Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient" "\". You'll see a window like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 msgid "" "The left and right boxes represent the start and end colors. Click on each " "and then click the large square on the right to choose the color. For the " @@ -3664,24 +3666,24 @@ msgid "" "set it all the way to ``0``." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165 msgid "" "See :ref:`Particles2D ` for more details on using " "particle effects." msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1164 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169 msgid "Project Files" msgstr "" -#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166 +#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171 msgid "" "You can find a completed version of this project here: https://github.com/" "kidscancode/Godot3_dodge/releases" msgstr "" #: ../../docs/getting_started/step_by_step/exporting.rst:4 -#: ../../docs/getting_started/editor/command_line_tutorial.rst:123 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:128 msgid "Exporting" msgstr "" @@ -6426,7 +6428,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224 -msgid "The first section lists custom signals defined in ``player.GD``:" +msgid "The first section lists custom signals defined in ``Player.gd``:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226 @@ -6449,7 +6451,7 @@ msgid "" "right corner to open the Connect Signal window. On the left side you can " "pick the node that will listen to this signal. Select the ``GUI`` node. The " "right side of the screen lets you pack optional values with the signal. We " -"already took care of it in ``player.GD``. In general I recommend not to add " +"already took care of it in ``Player.gd``. In general I recommend not to add " "too many arguments using this window as they're less convenient than doing " "it from the code." msgstr "" @@ -6460,8 +6462,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248 msgid "" -"You can optionally connect nodes from the code. But doing it from the editor " -"has two advantages:" +"You can optionally connect nodes from the code. However doing it from the " +"editor has two advantages:" msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250 @@ -6483,7 +6485,7 @@ msgid "" "If you look to the right, there is a \"Make Function\" radio button that is " "on by default. Click the connect button at the bottom of the window. Godot " "creates the method inside the ``GUI`` node. The script editor opens with the " -"cursor inside a new ``_on_player_health_changed`` function." +"cursor inside a new ``_on_Player_health_changed`` function." msgstr "" #: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265 @@ -6547,27 +6549,27 @@ msgid "" "It takes a new\\_value as its only argument:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327 msgid "This method needs to:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329 msgid "" "set the ``Number`` node's ``text`` to ``new_value`` converted to a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331 msgid "set the ``TextureProgress``'s ``value`` to ``new_value``" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:349 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350 msgid "" "``str`` is a built-in function that converts about any value to text. " "``Number``'s ``text`` property requires a string so we can't assign it to " "``new_value`` directly" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:353 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354 msgid "" "Also call ``update_health`` at the end of the ``_ready`` function to " "initialize the ``Number`` node's ``text`` with the right value at the start " @@ -6575,17 +6577,17 @@ msgid "" "attack!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:360 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361 msgid "" "Both the Number node and the TextureProgress update when the Player takes a " "hit" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:364 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365 msgid "Animate the loss of life with the Tween node" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:366 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367 msgid "" "Our interface is functional, but it could use some animation. That's a good " "opportunity to introduce the ``Tween`` node, an essential tool to animate " @@ -6595,54 +6597,54 @@ msgid "" "``health`` when the character takes damage." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:373 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374 msgid "" "The ``GUI`` scene already contains a ``Tween`` child node stored in the " "``tween`` variable. Let's now use it. We have to make some changes to " "``update_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:377 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378 msgid "" "We will use the ``Tween`` node's ``interpolate_property`` method. It takes " "seven arguments:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:380 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 msgid "A reference to the node who owns the property to animate" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 msgid "The property's identifier as a string" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 msgid "The starting value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 msgid "The end value" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 msgid "The animation's duration in seconds" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 msgid "The type of the transition" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387 msgid "The easing to use in combination with the equation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:388 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389 msgid "" "The last two arguments combined correspond to an `easing equation <#>`__. " "This controls how the value evolves from the start to the end point." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:392 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393 msgid "" "Click the script icon next to the ``GUI`` node to open it again. The " "``Number`` node needs text to update itself, and the ``Bar`` needs a float " @@ -6651,7 +6653,7 @@ msgid "" "variable named ``animated_health``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:398 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399 msgid "" "At the top of the script, define a new variable, name it " "``animated_health``, and set its value to 0. Navigate back to the " @@ -6660,18 +6662,18 @@ msgid "" "``interpolate_property`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:420 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421 msgid "Let's break down the call:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:426 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427 msgid "" "We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. " "``Tween``'s interpolate\\_property takes the property's name as a string. " "That's why we write it as ``\"animated_health\"``." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:434 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435 msgid "" "The starting point is the current value the bar's at. We still have to code " "this part, but it's going to be ``animated_health``. The end point of the " @@ -6679,7 +6681,7 @@ msgid "" "that's ``new_value``. And ``0.6`` is the animation's duration in seconds." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:444 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:445 msgid "" "The last two arguments are constants from the ``Tween`` class. " "``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't " @@ -6687,14 +6689,14 @@ msgid "" "or we'll get an error." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:449 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450 msgid "" "The animation will not play until we activated the ``Tween`` node with " "``tween.start()``. We only have to do this once if the node is not active. " "Add this code after the last line:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:469 msgid "" "Although we could animate the `health` property on the `Player`, we " "shouldn't. Characters should lose life instantly when they get hit. It makes " @@ -6704,60 +6706,60 @@ msgid "" "animations, check out `AnimationPlayer`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:471 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:472 msgid "Assign the animated\\_health to the LifeBar" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:473 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474 msgid "" "Now the ``animated_health`` variable animates but we don't update the actual " "``Bar`` and ``Number`` nodes anymore. Let's fix this." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:477 msgid "So far, the update\\_health method looks like this:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:500 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501 msgid "" "In this specific case, because ``number_label`` takes text, we need to use " "the ``_process`` method to animate it. Let's now update the ``Number`` and " "``TextureProgress`` nodes like before, inside of ``_process``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:523 msgid "" "`number_label` and `bar` are variables that store references to the `Number` " "and `TextureProgress` nodes." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:525 msgid "" "Play the game to see the bar animate smoothly. But the text displays decimal " "number and looks like a mess. And considering the style of the game, it'd be " "nice for the life bar to animate in a choppier fashion." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:530 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:531 msgid "The animation is smooth but the number is broken" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:532 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533 msgid "" "We can fix both problems by rounding out ``animated_health``. Use a local " "variable named ``round_value`` to store the rounded ``animated_health``. " "Then assign it to ``number_label.text`` and ``bar.value``:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:555 msgid "Try the game again to see a nice blocky animation." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:558 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559 msgid "By rounding out animated\\_health we hit two birds with one stone" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563 msgid "" "Every time the player takes a hit, the ``GUI`` calls " "``_on_Player_health_changed``, which in turn calls ``update_health``. This " @@ -6767,11 +6769,11 @@ msgid "" "damage, it happens in an instant." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:570 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:571 msgid "Fade the bar when the Player dies" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:572 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573 msgid "" "When the green character dies, it plays a death animation and fades out. At " "this point, we shouldn't show the interface anymore. Let's fade the bar as " @@ -6779,7 +6781,7 @@ msgid "" "manages multiple animations in parallel for us." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:577 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578 msgid "" "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to " "know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select " @@ -6787,15 +6789,15 @@ msgid "" "Inspector." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:582 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:583 msgid "Find the ``died`` signal, select it, and click the Connect button." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:586 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:587 msgid "The signal should already have the Enemy connected to it" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589 msgid "" "In the Connecting Signal window, connect to the ``GUI`` node again. The Path " "to Node should be ``../../GUI`` and the Method in Node should show " @@ -6804,38 +6806,38 @@ msgid "" "Script Workspace." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:596 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:597 msgid "You should get these values in the Connecting Signal window" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601 msgid "" "You should see a pattern by now: every time the GUI needs a new piece of " "information, we emit a new signal. Use them wisely: the more connections you " "add, the harder they are to track." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:603 msgid "" "To animate a fade on a UI element, we have to use its ``modulate`` property. " "``modulate`` is a ``Color`` that multiplies the colors of our textures." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:608 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:609 msgid "" "`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit " "from it. It lets you toggle the visibility of the node, assign a shader to " "it, and modify it using a color with `modulate`." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:610 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:611 msgid "" "``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and " "alpha. If we darken any of the first three channels it darkens the " "interface. If we lower the alpha channel our interface fades out." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:614 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:615 msgid "" "We're going to tween between two color values: from a white with an alpha of " "``1``, that is to say at full opacity, to a pure white with an alpha value " @@ -6844,20 +6846,20 @@ msgid "" "Use the ``Color()`` constructor to build two ``Color`` values." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:636 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:637 msgid "" "``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, " "respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is " "the alpha channel." msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:640 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:641 msgid "" "We then have to call the ``interpolate_property`` method of the ``Tween`` " "node again:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:653 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:654 msgid "" "This time we change the ``modulate`` property and have it animate from " "``start_color`` to the ``end_color``. The duration is of one second, with a " @@ -6865,15 +6867,15 @@ msgid "" "does not matter. Here's the complete ``_on_Player_died`` method:" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:678 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679 msgid "And that is it. You may now play the game to see the final result!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:682 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:683 msgid "The final result. Congratulations for getting there!" msgstr "" -#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:686 +#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687 msgid "" "Using the exact same techniques, you can change the color of the bar when " "the Player gets poisoned, turn the bar red when its health drops low, shake " @@ -7022,7 +7024,7 @@ msgid "The keyframe will be added in the animation player editor:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:62 -msgid "Move the editor cursor to the end, by clicking here:" +msgid "Move the editor cursor to the end by clicking here:" msgstr "" #: ../../docs/getting_started/step_by_step/animations.rst:66 @@ -7062,7 +7064,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:9 msgid "" "So far, :ref:`Nodes ` have been the most important datatype in " -"Godot, as most of the behaviors and features of the engine are implemented " +"Godot as most of the behaviors and features of the engine are implemented " "through them. There is another datatype that is equally important: :ref:" "`Resource `." msgstr "" @@ -7106,7 +7108,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:42 msgid "" "Typically, every object in Godot (Node, Resource, or anything else) can " -"export properties, properties can be of many types (like a string, integer, " +"export properties. Properties can be of many types (like a string, integer, " "Vector2, etc) and one of those types can be a resource. This means that both " "nodes and resources can contain resources as properties. To make it a little " "more visual:" @@ -7130,7 +7132,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:61 msgid "" -"Pressing the \">\" button on the right side of the preview allows to view " +"Pressing the \">\" button on the right side of the preview allows us to view " "and edit the resources properties. One of the properties (path) shows where " "it comes from. In this case, it comes from a png image." msgstr "" @@ -7166,7 +7168,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:101 msgid "" "The second way is more optimal, but only works with a string constant " -"parameter, because it loads the resource at compile-time." +"parameter because it loads the resource at compile-time." msgstr "" #: ../../docs/getting_started/step_by_step/resources.rst:116 @@ -7186,14 +7188,14 @@ msgid "" "` must be used." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:142 +#: ../../docs/getting_started/step_by_step/resources.rst:143 msgid "" "This method creates the nodes in the scene's hierarchy, configures them " "(sets all the properties) and returns the root node of the scene, which can " "be added to any other node." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:146 +#: ../../docs/getting_started/step_by_step/resources.rst:147 msgid "" "The approach has several advantages. As the :ref:`PackedScene.instance() " "` function is pretty fast, adding extra content " @@ -7203,11 +7205,11 @@ msgid "" "are all shared between the scene instances." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:155 +#: ../../docs/getting_started/step_by_step/resources.rst:156 msgid "Freeing resources" msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:157 +#: ../../docs/getting_started/step_by_step/resources.rst:158 msgid "" "Resource extends from :ref:`Reference `. As such, when a " "resource is no longer in use, it will automatically free itself. Since, in " @@ -7215,7 +7217,7 @@ msgid "" "when a node is removed or freed, all the children resources are freed too." msgstr "" -#: ../../docs/getting_started/step_by_step/resources.rst:166 +#: ../../docs/getting_started/step_by_step/resources.rst:167 msgid "" "Like any object in Godot, not just nodes, resources can be scripted, too. " "However, there isn't generally much of an advantage, as resources are just " @@ -7229,7 +7231,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:9 msgid "" "File systems are yet another hot topic in engine development. The file " -"system manages how the assets are stored, and how they are accessed. A well " +"system manages how the assets are stored and how they are accessed. A well " "designed file system also allows multiple developers to edit the same source " "files and assets while collaborating together." msgstr "" @@ -7244,7 +7246,7 @@ msgid "" msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:21 -#: ../../docs/tutorials/3d/inverse_kinematics.rst:64 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:68 msgid "Implementation" msgstr "" @@ -7368,7 +7370,7 @@ msgid "" "To avoid this, do all your move, delete and rename operations from within " "Godot, on the FileSystem dock. Never move assets from outside Godot, or " "dependencies will have to be fixed manually (Godot detects this and helps " -"you fix them anyway, but why going the hardest route?)." +"you fix them anyway, but why go the hard route?)." msgstr "" #: ../../docs/getting_started/step_by_step/filesystem.rst:108 @@ -7410,8 +7412,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:16 msgid "" "This concept deserves going into a little more detail. In fact, the scene " -"system is not even a core component of Godot, as it is possible to skip it " -"and write a script (or C++ code) that talks directly to the servers. But " +"system is not even a core component of Godot as it is possible to skip it " +"and write a script (or C++ code) that talks directly to the servers, but " "making a game that way would be a lot of work." msgstr "" @@ -7445,7 +7447,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:43 msgid "" -"One of the ways to explain how Godot works, is that it's a high level game " +"One of the ways to explain how Godot works is that it's a high level game " "engine over a low level middleware." msgstr "" @@ -7471,19 +7473,19 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:57 msgid "" "It contains the root :ref:`Viewport `, to which a scene is " -"added as a child when it's first opened, to become part of the *Scene Tree* " +"added as a child when it's first opened to become part of the *Scene Tree* " "(more on that next)" msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:60 msgid "" -"It contains information about the groups, and has means to call all nodes in " -"a group, or get a list of them." +"It contains information about the groups and has the means to call all nodes " +"in a group or get a list of them." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:62 msgid "" -"It contains some global state functionality, such as setting pause mode, or " +"It contains some global state functionality, such as setting pause mode or " "quitting the process." msgstr "" @@ -7508,7 +7510,7 @@ msgstr "" msgid "" "This node contains the main viewport, anything that is a child of a :ref:" "`Viewport ` is drawn inside of it by default, so it makes " -"sense that the top of all nodes is always a node of this type, otherwise " +"sense that the top of all nodes is always a node of this type otherwise " "nothing would be seen!" msgstr "" @@ -7531,7 +7533,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:103 msgid "" -"This means that, as explained in previous tutorials, it will get the " +"This means that as explained in previous tutorials, it will get the " "_enter_tree() and _ready() callbacks (as well as _exit_tree())." msgstr "" @@ -7549,7 +7551,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:116 msgid "" -"Most node operations in Godot, such as drawing 2D, processing or getting " +"Most node operations in Godot, such as drawing 2D, processing, or getting " "notifications are done in tree order. This means that parents and siblings " "with a smaller rank in the tree order will get notified before the current " "node." @@ -7566,8 +7568,8 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:127 msgid "" "The root node of that scene (only one root, remember?) is added as either a " -"child of the \"root\" Viewport (from SceneTree), or to any child or grand-" -"child of it." +"child of the \"root\" Viewport (from SceneTree), or to any child or " +"grandchild of it." msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:130 @@ -7602,7 +7604,7 @@ msgstr "" #: ../../docs/getting_started/step_by_step/scene_tree.rst:161 msgid "" -"This is a quick and useful way to switch scenes, but has the drawback that " +"This is a quick and useful way to switch scenes but has the drawback that " "the game will stall until the new scene is loaded and running. At some point " "in your game, it may be desired to create proper loading screens with " "progress bar, animated indicators or thread (background) loading. This must " @@ -7773,7 +7775,7 @@ msgid "" "current scene and replaces it with the requested one." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:218 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216 msgid "" "As mentioned in the comments above, we want to avoid the situation of having " "the current scene being deleted while being used (code from functions of it " @@ -7783,25 +7785,25 @@ msgid "" "when no code from the current scene is running." msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:226 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224 msgid "" "Finally, all that is left is to fill the empty functions in scene_a.gd and " "scene_b.gd:" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:247 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245 #: ../../docs/tutorials/math/vector_math.rst:276 #: ../../docs/development/cpp/core_types.rst:122 msgid "and" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:267 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265 msgid "" "Now if you run the project, you can switch between both scenes by pressing " "the button!" msgstr "" -#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:270 +#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268 msgid "" "To load scenes with a progress bar, check out the next tutorial, :ref:" "`doc_background_loading`" @@ -7822,183 +7824,183 @@ msgid "" "the world of Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:13 +#: ../../docs/getting_started/editor/unity_to_godot.rst:14 msgid "Differences" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Unity" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:16 +#: ../../docs/getting_started/editor/unity_to_godot.rst:17 msgid "Godot" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 #: ../../docs/community/contributing/documentation_guidelines.rst:102 msgid "License" msgstr "授權" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "" "Proprietary, closed, free license with revenue caps and usage restrictions" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:18 +#: ../../docs/getting_started/editor/unity_to_godot.rst:19 msgid "MIT license, free and fully open source without any restriction" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "OS (editor)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, Linux (unofficial and unsupported)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:20 +#: ../../docs/getting_started/editor/unity_to_godot.rst:21 msgid "Windows, macOS, X11 (Linux, \\*BSD)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "OS (export)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, Linux" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS, Windows Phone, Tizen" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly or asm.js" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "" "**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, " "HoloLens" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:27 +#: ../../docs/getting_started/editor/unity_to_godot.rst:28 msgid "**TV:** Android TV, Samsung SMART TV, tvOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:22 +#: ../../docs/getting_started/editor/unity_to_godot.rst:23 msgid "**Desktop:** Windows, macOS, X11" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:23 +#: ../../docs/getting_started/editor/unity_to_godot.rst:24 msgid "**Mobile:** Android, iOS" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:24 +#: ../../docs/getting_started/editor/unity_to_godot.rst:25 msgid "**Web:** WebAssembly" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:25 +#: ../../docs/getting_started/editor/unity_to_godot.rst:26 msgid "**Console:** See :ref:`doc_consoles`" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:26 +#: ../../docs/getting_started/editor/unity_to_godot.rst:27 msgid "**VR:** Oculus Rift, SteamVR" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Scene system" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "Component/Scene (GameObject > Component)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:30 +#: ../../docs/getting_started/editor/unity_to_godot.rst:31 msgid "Prefabs" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:29 +#: ../../docs/getting_started/editor/unity_to_godot.rst:30 msgid "" ":ref:`Scene tree and nodes `, allowing scenes to be " "nested and/or inherit other scenes" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Third-party tools" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid "Visual Studio or VS Code" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:32 +#: ../../docs/getting_started/editor/unity_to_godot.rst:33 msgid ":ref:`External editors are possible `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:33 +#: ../../docs/getting_started/editor/unity_to_godot.rst:34 msgid ":ref:`Android SDK for Android export `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Killer features" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Huge community" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid "Large assets store" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:35 +#: ../../docs/getting_started/editor/unity_to_godot.rst:36 msgid "Scene System" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:36 +#: ../../docs/getting_started/editor/unity_to_godot.rst:37 msgid ":ref:`Animation Pipeline `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:37 +#: ../../docs/getting_started/editor/unity_to_godot.rst:38 msgid ":ref:`Easy to write Shaders `" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:38 +#: ../../docs/getting_started/editor/unity_to_godot.rst:39 msgid "Debug on Device" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:45 +#: ../../docs/getting_started/editor/unity_to_godot.rst:46 msgid "The editor" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:47 +#: ../../docs/getting_started/editor/unity_to_godot.rst:48 msgid "" "Godot Engine provides a rich-featured editor that allows you to build your " "games. The pictures below display both editors with colored blocks to " "indicate common functionalities." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:53 +#: ../../docs/getting_started/editor/unity_to_godot.rst:55 msgid "" "Note that Godot editor allows you to dock each panel at the side of the " "scene editor you wish." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:55 +#: ../../docs/getting_started/editor/unity_to_godot.rst:57 msgid "" "While both editors may seem similar, there are many differences below the " -"surface. Both let you organize the project using the filesystem, but Godot " -"approach is simpler, with a single configuration file, minimalist text " +"surface. Both let you organize the project using the filesystem, but Godot's " +"approach is simpler with a single configuration file, minimalist text " "format, and no metadata. All this contributes to Godot being much friendlier " -"to VCS systems such as Git, Subversion or Mercurial." +"to VCS systems such as Git, Subversion, or Mercurial." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:57 +#: ../../docs/getting_started/editor/unity_to_godot.rst:62 msgid "" "Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node " "has a specific function, the approach used by Godot is more visually " @@ -8006,17 +8008,17 @@ msgid "" "does at a glance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:59 +#: ../../docs/getting_started/editor/unity_to_godot.rst:66 msgid "" "The Inspector in Godot is more minimalist and designed to only show " "properties. Thanks to this, objects can export a much larger amount of " -"useful parameters to the user, without having to hide functionality in " +"useful parameters to the user without having to hide functionality in " "language APIs. As a plus, Godot allows animating any of those properties " -"visually, so changing colors, textures, enumerations or even links to " +"visually, so changing colors, textures, enumerations, or even links to " "resources in real-time is possible without involving code." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:61 +#: ../../docs/getting_started/editor/unity_to_godot.rst:71 msgid "" "Finally, the Toolbar at the top of the screen is similar in the sense that " "it allows controlling the project playback, but projects in Godot run in a " @@ -8024,139 +8026,139 @@ msgid "" "objects can still be explored in the debugger window)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:63 +#: ../../docs/getting_started/editor/unity_to_godot.rst:75 msgid "" "This approach has the disadvantage that the running game can't be explored " -"from different angles (though this may be supported in the future, and " +"from different angles (though this may be supported in the future and " "displaying collision gizmos in the running game is already possible), but in " "exchange has several advantages:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:65 +#: ../../docs/getting_started/editor/unity_to_godot.rst:79 msgid "" "Running the project and closing it is fast (Unity has to save, run the " -"project, close the project and then reload the previous state)." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:66 -msgid "" -"Live editing is a lot more useful, because changes done to the editor take " -"effect immediately in the game, and are not lost (nor have to be synced) " -"when the game is closed. This allows fantastic workflows, like creating " -"levels while you play them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:67 -msgid "The editor is more stable, because the game runs in a separate process." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:69 -msgid "" -"Finally, the top toolbar includes a menu for remote debugging. These options " -"make it simple to deploy to a device (connected phone, tablet or browser via " -"HTML5), and debug/live edit on it after the game was exported." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:72 -msgid "The scene system" -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:74 -msgid "" -"This is the most important difference between Unity and Godot, and actually " -"the favourite feature of most Godot users." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:76 -msgid "" -"Unity's scene system consist in embedding all the required assets in a " -"scene, and link them together by setting components and scripts to them." -msgstr "" - -#: ../../docs/getting_started/editor/unity_to_godot.rst:78 -msgid "" -"Godot's scene system is different: it actually consists in a tree made of " -"nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is " -"similar to Unity scene system. However, each node can have multiple " -"children, which make each a subscene of the main scene. This means you can " -"compose a whole scene with different scenes, stored in different files." +"project, close the project, and then reload the previous state)." msgstr "" #: ../../docs/getting_started/editor/unity_to_godot.rst:80 msgid "" +"Live editing is a lot more useful because changes done to the editor take " +"effect immediately in the game and are not lost (nor have to be synced) when " +"the game is closed. This allows fantastic workflows, like creating levels " +"while you play them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:81 +msgid "The editor is more stable because the game runs in a separate process." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +msgid "" +"Finally, the top toolbar includes a menu for remote debugging. These options " +"make it simple to deploy to a device (connected phone, tablet, or browser " +"via HTML5), and debug/live edit on it after the game was exported." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +msgid "The scene system" +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +msgid "" +"This is the most important difference between Unity and Godot and, actually, " +"the favourite feature of most Godot users." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +msgid "" +"Unity's scene system consists of embedding all the required assets in a " +"scene and linking them together by setting components and scripts to them." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:95 +msgid "" +"Godot's scene system is different: it actually consists in a tree made of " +"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this " +"is similar to Unity scene system. However, each node can have multiple " +"children, which makes each a subscene of the main scene. This means you can " +"compose a whole scene with different scenes stored in different files." +msgstr "" + +#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +msgid "" "For example, think of a platformer level. You would compose it with multiple " "elements:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:82 +#: ../../docs/getting_started/editor/unity_to_godot.rst:102 msgid "Bricks" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:83 +#: ../../docs/getting_started/editor/unity_to_godot.rst:103 msgid "Coins" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:84 +#: ../../docs/getting_started/editor/unity_to_godot.rst:104 msgid "The player" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:85 +#: ../../docs/getting_started/editor/unity_to_godot.rst:105 msgid "The enemies" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:88 +#: ../../docs/getting_started/editor/unity_to_godot.rst:108 msgid "" "In Unity, you would put all the GameObjects in the scene: the player, " "multiple instances of enemies, bricks everywhere to form the ground of the " -"level, and multiple instances of coins all over the level. You would then " -"add various components to each element to link them and add logic in the " -"level: for example, you'd add a BoxCollider2D to all the elements of the " +"level and then multiple instances of coins all over the level. You would " +"then add various components to each element to link them and add logic in " +"the level: For example, you'd add a BoxCollider2D to all the elements of the " "scene so that they can collide. This principle is different in Godot." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:90 +#: ../../docs/getting_started/editor/unity_to_godot.rst:113 msgid "" "In Godot, you would split your whole scene into 3 separate, smaller scenes, " "which you would then instance in the main scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:92 +#: ../../docs/getting_started/editor/unity_to_godot.rst:115 msgid "**First, a scene for the Player alone.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:94 +#: ../../docs/getting_started/editor/unity_to_godot.rst:117 msgid "" "Consider the player as a reusable element in other levels. It is composed of " "one node in particular: an AnimatedSprite node, which contains the sprite " "textures to form various animations (for example, walking animation)" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:96 +#: ../../docs/getting_started/editor/unity_to_godot.rst:120 msgid "**Second, a scene for the Enemy.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:98 +#: ../../docs/getting_started/editor/unity_to_godot.rst:122 msgid "" "There again, an enemy is a reusable element in other levels. It is almost " "the same as the Player node - the only differences are the script (that " "manages AI, mostly) and sprite textures used by the AnimatedSprite." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:100 +#: ../../docs/getting_started/editor/unity_to_godot.rst:126 msgid "**Lastly, the Level scene.**" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:102 +#: ../../docs/getting_started/editor/unity_to_godot.rst:128 msgid "" "It is composed of Bricks (for platforms), Coins (for the player to grab) and " "a certain number of instances of the previous Enemy scene. These will be " "different, separate enemies, whose behaviour and appearance will be the same " "as defined in the Enemy scene. Each instance is then considered as a node in " "the Level scene tree. Of course, you can set different properties for each " -"enemy node (to change its color for example)." +"Enemy node (to change its color, for example)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:104 +#: ../../docs/getting_started/editor/unity_to_godot.rst:134 msgid "" "Finally, the main scene would then be composed of one root node with 2 " "children: a Player instance node, and a Level instance node. The root node " @@ -8166,7 +8168,7 @@ msgid "" "all GUI-related nodes)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:108 +#: ../../docs/getting_started/editor/unity_to_godot.rst:140 msgid "" "As you can see, every scene is organized as a tree. The same goes for nodes' " "properties: you don't *add* a collision component to a node to make it " @@ -8176,69 +8178,69 @@ msgid "" "introduction `)." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:110 +#: ../../docs/getting_started/editor/unity_to_godot.rst:145 msgid "" "Question: What are the advantages of this system? Wouldn't this system " "potentially increase the depth of the scene tree? Besides, Unity allows " "organizing GameObjects by putting them in empty GameObjects." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:112 +#: ../../docs/getting_started/editor/unity_to_godot.rst:147 msgid "" -"First, this system is closer to the well-known Object-Oriented paradigm: " +"First, this system is closer to the well-known object-oriented paradigm: " "Godot provides a number of nodes which are not clearly \"Game Objects\", but " "they provide their children with their own capabilities: this is inheritance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:113 +#: ../../docs/getting_started/editor/unity_to_godot.rst:148 msgid "" "Second, it allows the extraction a subtree of scene to make it a scene of " -"its own, which answers to the second and third questions: even if a scene " -"tree gets too deep, it can be split into smaller subtrees. This also allows " -"a better solution for reusability, as you can include any subtree as a child " +"its own, which answers the second and third questions: even if a scene tree " +"gets too deep, it can be split into smaller subtrees. This also allows a " +"better solution for reusability, as you can include any subtree as a child " "of any node. Putting multiple nodes in an empty GameObject in Unity does not " "provide the same possibility, apart from a visual organization." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:116 +#: ../../docs/getting_started/editor/unity_to_godot.rst:151 msgid "" "These are the most important concepts you need to remember: \"node\", " -"\"parent node\" and \"child node\"." +"\"parent node\", and \"child node\"." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:120 +#: ../../docs/getting_started/editor/unity_to_godot.rst:155 #: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4 msgid "Project organization" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:124 +#: ../../docs/getting_started/editor/unity_to_godot.rst:159 msgid "" "We previously observed that there is no perfect solution to set a project " "architecture. Any solution will work for Unity and Godot, so this point has " "a lesser importance." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:126 +#: ../../docs/getting_started/editor/unity_to_godot.rst:162 msgid "" "However, we often observe a common architecture for Unity projects, which " -"consists in having one Assets folder in the root directory, that contains " +"consists of having one Assets folder in the root directory that contains " "various folders, one per type of asset: Audio, Graphics, Models, Materials, " "Scripts, Scenes, etc." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:128 +#: ../../docs/getting_started/editor/unity_to_godot.rst:165 msgid "" -"As described before, Godot scene system allows splitting scenes in smaller " -"scenes. Since each scene and subscene is actually one scene file in the " -"project, we recommend organizing your project a bit differently. This wiki " -"provides a page for this: :ref:`doc_project_organization`." +"As described before, the Godot scene system allows splitting scenes into " +"smaller scenes. Since each scene and subscene is actually one scene file in " +"the project, we recommend organizing your project a bit differently. This " +"wiki provides a page for this: :ref:`doc_project_organization`." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:132 +#: ../../docs/getting_started/editor/unity_to_godot.rst:171 msgid "Where are my prefabs?" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:134 +#: ../../docs/getting_started/editor/unity_to_godot.rst:173 msgid "" "The concept of prefabs as provided by Unity is a 'template' element of the " "scene. It is reusable, and each instance of the prefab that exists in the " @@ -8246,125 +8248,125 @@ msgid "" "as defined by the prefab." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:136 +#: ../../docs/getting_started/editor/unity_to_godot.rst:177 msgid "" -"Godot does not provide prefabs as such, but this functionality is here again " -"filled thanks to its scene system: as we saw the scene system is organized " -"as a tree. Godot allows you to save a subtree of a scene as its own scene, " -"thus saved in its own file. This new scene can then be instanced as many " -"times as you want. Any change you make to this new, separate scene will be " -"applied to its instances. However, any change you make to the instance will " -"not have any impact on the 'template' scene." +"Godot does not provide prefabs as such, but this functionality is here, " +"again, filled thanks to its scene system: As we saw the scene system is " +"organized as a tree. Godot allows you to save a subtree of a scene as its " +"own scene, thus saved into its own file. This new scene can then be " +"instanced as many times as you want. Any change you make to this new, " +"separate scene will be applied to its instances. However, any change you " +"make to the instance will not have any impact on the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:140 +#: ../../docs/getting_started/editor/unity_to_godot.rst:185 msgid "" "To be precise, you can modify the parameters of the instance in the " "Inspector panel. However, the nodes that compose this instance are locked " -"and you can unlock them if you need to by right clicking the instance in the " -"Scene tree, and selecting \"Editable children\" in the menu. You don't need " -"to do this to add new children nodes to this node, but remember that these " -"new children will belong to the instance, not the 'template' scene. If you " -"want to add new children to all the instances of your 'template' scene, then " -"you need to add it once in the 'template' scene." +"although you can unlock them if you need to by right-clicking the instance " +"in the Scene tree and selecting \"Editable children\" in the menu. You don't " +"need to do this to add new children nodes to this node, but it is possible. " +"Remember that these new children will belong to the instance, not the " +"'template' scene. If you want to add new children to all the instances of " +"your 'template' scene, then you need to add them in the 'template' scene." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:145 +#: ../../docs/getting_started/editor/unity_to_godot.rst:195 msgid "Glossary correspondence" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:147 +#: ../../docs/getting_started/editor/unity_to_godot.rst:197 msgid "" "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized " "branch" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:153 +#: ../../docs/getting_started/editor/unity_to_godot.rst:203 msgid "Scripting: GDScript, C# and Visual Script" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:156 +#: ../../docs/getting_started/editor/unity_to_godot.rst:206 msgid "Design" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:158 +#: ../../docs/getting_started/editor/unity_to_godot.rst:208 msgid "" "As you may know already, Unity supports C#. C# benefits from its integration " "with Visual Studio and other features, such as static typing." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:160 +#: ../../docs/getting_started/editor/unity_to_godot.rst:210 msgid "" "Godot provides its own scripting language, :ref:`GDScript ` " "as well as support for :ref:`Visual Script ` and :ref:`C# `. GDScript borrows its syntax " -"from Python, but is not related to it. If you wonder about the reasoning for " -"a custom scripting language, please read :ref:`GDScript ` and " -"`FAQ `_ pages. GDScript is strongly attached to the Godot API, but it " -"is easy to learn." +"visual_script>` and :ref:`doc_c_sharp`. GDScript borrows its syntax from " +"Python, but is not related to it. If you wonder about the reasoning for a " +"custom scripting language, please read :ref:`GDScript ` and " +"`FAQ `_ pages. GDScript is strongly attached to the Godot API and is " +"really easy to learn: Between one evening for an experienced programmer and " +"a week for a complete beginner." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:162 +#: ../../docs/getting_started/editor/unity_to_godot.rst:216 msgid "" "Unity allows you to attach as many scripts as you want to a GameObject. Each " -"script adds a behaviour to the GameObject: for example, you can attach a " +"script adds a behaviour to the GameObject: For example, you can attach a " "script so that it reacts to the player's controls, and another that controls " "its specific game logic." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:164 +#: ../../docs/getting_started/editor/unity_to_godot.rst:220 msgid "" "In Godot, you can only attach one script per node. You can use either an " -"external GDScript file, or include it directly in the node. If you need to " -"attach more scripts to one node, then you may consider two solutions, " -"depending on your scene and on what you want to achieve:" +"external GDScript file or include the script directly in the node. If you " +"need to attach more scripts to one node, then you may consider two " +"solutions, depending on your scene and on what you want to achieve:" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:166 +#: ../../docs/getting_started/editor/unity_to_godot.rst:224 msgid "" "either add a new node between your target node and its current parent, then " "add a script to this new node." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:167 +#: ../../docs/getting_started/editor/unity_to_godot.rst:225 msgid "" "or, your can split your target node into multiple children and attach one " "script to each of them." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:169 +#: ../../docs/getting_started/editor/unity_to_godot.rst:227 msgid "" "As you can see, it can be easy to turn a scene tree to a mess. This is why " -"it is important to have a real reflection, and consider splitting a " +"it is important to have a real reflection and consider splitting a " "complicated scene into multiple, smaller branches." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:172 +#: ../../docs/getting_started/editor/unity_to_godot.rst:231 msgid "Connections : groups and signals" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:174 +#: ../../docs/getting_started/editor/unity_to_godot.rst:233 msgid "" -"You can control nodes by accessing them using a script, and call functions " -"(built-in or user-defined) on them. But there's more: you can also place " +"You can control nodes by accessing them using a script and calling functions " +"(built-in or user-defined) on them. But there's more: You can also place " "them in a group and call a function on all nodes contained in this group! " "This is explained in :ref:`this page `." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:176 +#: ../../docs/getting_started/editor/unity_to_godot.rst:237 msgid "" "But there's more! Certain nodes throw signals when certain actions happen. " "You can connect these signals to call a specific function when they happen. " "Note that you can define your own signals and send them whenever you want. " -"This feature is documented `here <../scripting/gdscript/gdscript_basics." -"html#signals>`_." +"This feature is documented `here `_." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:180 +#: ../../docs/getting_started/editor/unity_to_godot.rst:243 msgid "Using Godot in C++" msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:182 +#: ../../docs/getting_started/editor/unity_to_godot.rst:245 msgid "" "For your information, Godot also allows you to develop your project directly " "in C++ by using its API, which is not possible with Unity at the moment. As " @@ -8372,7 +8374,7 @@ msgid "" "++ using Godot API." msgstr "" -#: ../../docs/getting_started/editor/unity_to_godot.rst:184 +#: ../../docs/getting_started/editor/unity_to_godot.rst:247 msgid "" "If you are interested in using Godot in C++, you may want to start reading " "the :ref:`Developing in C++ ` page." @@ -8396,7 +8398,7 @@ msgstr "路徑" #: ../../docs/getting_started/editor/command_line_tutorial.rst:17 msgid "" -"It is recommended that your godot binary is in your PATH environment " +"It is recommended that your Godot binary is in your PATH environment " "variable, so it can be executed easily from any place by typing ``godot``. " "You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and " "making sure it is called ``godot``." @@ -8433,79 +8435,79 @@ msgstr "" msgid "Creating a project" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:51 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:52 msgid "" -"To create a project from the command line, navigate the to the desired place " -"and create an empty project.godot file." +"Creating a project from the command line can be done by navigating the shell " +"to the desired place and making a project.godot file." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:59 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:63 msgid "The project can now be opened with Godot." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:62 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:67 msgid "Running the editor" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:64 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:69 msgid "" "Running the editor is done by executing godot with the ``-e`` flag. This " -"must be done from within the project directory, or a subdirectory, otherwise " +"must be done from within the project directory or a subdirectory, otherwise " "the command is ignored and the project manager appears." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:72 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:77 msgid "" "If a scene has been created and saved, it can be edited later by running the " "same code with that scene as argument." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:80 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:85 msgid "Erasing a scene" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:82 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:87 msgid "" -"Godot is friends with your filesystem, and will not create extra metadata " -"files, simply use ``rm`` to erase a file. Make sure nothing references that " -"scene, or else an error will be thrown upon opening." +"Godot is friends with your filesystem and will not create extra metadata " +"files. Use ``rm`` to erase a scene file. Make sure nothing references that " +"scene or else an error will be thrown upon opening." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:91 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:96 msgid "Running the game" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:93 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:98 msgid "" "To run the game, simply execute Godot within the project directory or " "subdirectory." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:100 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:105 msgid "" "When a specific scene needs to be tested, pass that scene to the command " "line." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:108 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:113 msgid "Debugging" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:110 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:115 msgid "" "Catching errors in the command line can be a difficult task because they " "just fly by. For this, a command line debugger is provided by adding ``-d``. " "It works for both running the game or a simple scene." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:125 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:130 msgid "" "Exporting the project from the command line is also supported. This is " "especially useful for continuous integration setups. The version of Godot " "that is headless (server build, no video) is ideal for this." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:134 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:139 msgid "" "The platform names recognized by the ``--export`` switch are the same as " "displayed in the export wizard of the editor. To get a list of supported " @@ -8513,36 +8515,36 @@ msgid "" "and the full listing of platforms your configuration supports will be shown." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:140 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:145 msgid "" "To export a debug version of the game, use the ``--export-debug`` switch " "instead of ``--export``. Their parameters and usage are the same." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:144 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:149 msgid "Running a script" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:146 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:151 msgid "" "It is possible to run a simple .gd script from the command line. This " "feature is especially useful in large projects, for batch conversion of " "assets or custom import/export." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:150 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:155 msgid "The script must inherit from SceneTree or MainLoop." msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:152 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:157 msgid "Here is a simple example of how it works:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:163 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:168 msgid "And how to run it:" msgstr "" -#: ../../docs/getting_started/editor/command_line_tutorial.rst:170 +#: ../../docs/getting_started/editor/command_line_tutorial.rst:175 msgid "" "If no project.godot exists at the path, current path is assumed to be the " "current working directory (unless ``-path`` is specified)." @@ -11790,10 +11792,10 @@ msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147 msgid "" "As it can be seen above, the type and initial value of the variable can be " -"changed, as well as some property hints (@TODO, document this). Ticking the " -"\"Export\" options makes the variable visible in the Inspector when " -"selecting the node. This also makes it available to other scripts via the " -"method described in the previous step." +"changed, as well as some property hints. Ticking the \"Export\" options " +"makes the variable visible in the Inspector when selecting the node. This " +"also makes it available to other scripts via the method described in the " +"previous step." msgstr "" #: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153 @@ -12844,7 +12846,7 @@ msgstr "" #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116 #: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133 #: ../../docs/tutorials/2d/particle_systems_2d.rst:265 -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81 #: ../../docs/tutorials/math/matrices_and_transforms.rst:309 msgid "Scale" msgstr "" @@ -13489,6 +13491,257 @@ msgid "" "a .gdignore file." msgstr "" +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2 +msgid "Godot-Blender-Exporter" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5 +msgid "Details on exporting" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16 +msgid "Disabling specific objects" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17 +msgid "" +"Sometimes you don't want some objects exported (eg high-res models used for " +"baking). An object will not be exported if it is not rendered in the scene. " +"This can be set in the outliner:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:23 +msgid "" +"Objects hidden in the viewport will be exported, but will be hidden in the " +"Godot scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:28 +msgid "Build Pipeline Integration" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29 +msgid "" +"If you have hundreds of model files, you don't want your artists to waste " +"time manually exporting their blend files. To combat this, the exporter " +"provides a python function ``io_scene_godot.export(out_file_path)`` that can " +"be called to export a file. This allows easy integration with other build " +"systems. An example Makefile and python script that exports all the blends " +"in a directory is present in the Godot-Blender-exporter repository." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +msgid "Materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5 +msgid "Using existing Godot materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:6 +msgid "" +"One way in which the exporter can handle materials is to attempt to match " +"the Blender material with an existing Godot material. This has the advantage " +"of being able to use all of the features of Godot's material system, but it " +"means that you cannot see your model with the material applied inside " +"Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:11 +msgid "" +"To do this, the exporter attempts to find Godot materials with names that " +"match those of the material name in Blender. So if you export an object in " +"Blender with the material name ``PurpleDots`` then the exporter will search " +"for the file ``PurpleDots.tres`` and assign it to the object. If this file " +"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, " +"then the exporter will fall back to exporting the material from Blender." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:19 +msgid "" +"Where the exporter searches for the ``.tres`` file is determined by the " +"\"Material Search Paths\" option:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33 +msgid "This can take the value of:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25 +msgid "" +"Project Directory - Attempts to find the ``project.Godot`` and recursively " +"searches through subdirectories. If ``project.Godot`` cannot be found it " +"will throw an error. This is useful for most projects where naming conflicts " +"are unlikely." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:29 +msgid "" +"Export Directory - Look for materials in subdirectories of the export " +"location. This is useful for projects where you may have duplicate material " +"names and need more control over what material gets assigned." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:32 +msgid "None - Do not search for materials. Export them from the Blender file." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36 +msgid "Export of Blender materials" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38 +msgid "" +"The other way materials are handled is for the exporter to export them from " +"Blender. Currently only the diffuse color and a few flags (eg unshaded) are " +"exported." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43 +msgid "" +"Export of Blender materials is currently very primitive. However, it is the " +"focus of a current GSOC project" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47 +msgid "" +"Materials are currently exported using their \"Blender Render\" settings. " +"When Blender 2.8 is released, this will be removed and this part of the " +"exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2 +#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 +msgid "Lights" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4 +msgid "" +"By default, lamps in Blender have shadows enabled. This can cause " +"performance issues in Godot." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8 +msgid "" +"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 " +"is released, this will be removed and this part of the exporter will change." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11 +msgid "" +"Sun, point and spot lamps are all exported from Blender along with many of " +"their properties:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16 +#, fuzzy +msgid "There are some things to note:" +msgstr "Godot 沒有使用限制" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18 +msgid "" +"In Blender, a light casts light all the way to infinity. In Godot, it is " +"clamped by the attenuation distance. To most closely match between the " +"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21 +msgid "" +"Light attenuation models differ between Godot and Blender. The exporter " +"attempts to make them match, but it isn't always very good." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23 +msgid "" +"Spotlight angular attenuation models also differ between Godot and Blender. " +"The exporter attempts to make them similar, but it doesn't always look the " +"same." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26 +msgid "" +"There is no difference between buffer shadow and ray shadow in the export." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2 +msgid "Physics Properties" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3 +msgid "" +"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders " +"physics tab:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9 +msgid "" +"By default, a single Blender object with rigid body enabled will export as " +"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14 +msgid "Body Type" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:15 +msgid "" +"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. " +"These turn into Static and RigidBody nodes. To create a kinematic body, " +"enable the \"animated\" checkbox on an \"Active\" body:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23 +#: ../../docs/tutorials/physics/physics_introduction.rst:55 +msgid "Collision Shapes" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24 +msgid "" +"Many of the parameters for collision shapes are missing from Blender, and " +"many of the collision shapes are also not present. However, almost all of " +"the options in Blender's rigid body collision and rigid body dynamics " +"interfaces are supported:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:38 +msgid "There are the following caveats:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32 +msgid "" +"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex " +"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender " +"and Godot" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:35 +msgid "" +"In Godot, you can have different collision groups and collision masks. In " +"Blender you only have collision groups. As a result, the exported object's " +"collision mask is equal to it's collision group. Most of the time, this is " +"what you want." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47 +msgid "Collision Geometry Only" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:48 +msgid "" +"Frequently you want different geometry for your collision meshes and your " +"graphical meshes, but by default the exporter will export a mesh along with " +"the collision shape. To only export the collision shape, set the objects " +"maximum draw type to Wire:" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55 +msgid "" +"This will also influence how the object is shown in Blender's viewport. Most " +"of the time, you want your collision geometry to be shown see-through when " +"working on the models, so this works out fairly nicely." +msgstr "" + #: ../../docs/getting_started/workflow/assets/index.rst:2 msgid "Assets workflow" msgstr "" @@ -14390,136 +14643,150 @@ msgid "" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53 -msgid "Import workflows" +msgid "Exporting ESCN files from Blender" msgstr "" #: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55 msgid "" +"The most powerful one, called `godot-blender-exporter `__. It uses .escn files which is kind of " +"another name of .tscn file(Godot scene file), it keeps as much information " +"as possible from a Blender scene." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +msgid "" +"ESCN exporter has a detailed `document `__ " +"describing its functionality and usage." +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64 +msgid "Import workflows" +msgstr "" + +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +msgid "" "Godot scene importer allows different workflows regarding how data is " "imported. Depending on many options, it is possible to import a scene with:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 msgid "" "External materials (default): Where each material is saved to a file " "resource. Modifications to them are kept." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:59 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70 msgid "" "External meshes: Where each mesh is saved to a different file. Many users " "prefer to deal with meshes directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 msgid "" "External animations: Allowing saved animations to be modified and merged " "when sources change." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72 msgid "" "External scenes: Save the root nodes of the imported scenes each as a " "separate scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:62 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73 msgid "Single Scene: A single scene file with everything built in." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77 msgid "" "As different developers have different needs, this import process is highly " "customizable." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80 msgid "Import Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82 msgid "The importer has several options, which will be discussed below:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87 msgid "Nodes:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90 msgid "Root Type" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92 msgid "" "By default, the type of the root node in imported scenes is \"Spatial\", but " "this can be modified." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:84 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 msgid "Root Name" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97 msgid "Allows setting a specific name to the generated root node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100 msgid "Custom Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102 msgid "" "A special script to process the whole scene after import can be provided. " "This is great for post processing, changing materials, doing funny stuff " "with the geometry etc." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:95 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 msgid "Create a script that like this:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 msgid "" "The post-import function takes the imported scene as argument (the parameter " "is actually the root node of the scene). The scene that will finally be used " "must be returned. It can be a different one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:122 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236 msgid "Storage" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 msgid "" "By default, Godot imports a single scene. This option allows specifying that " "nodes below the root will each be a separate scene and instanced into the " "imported one." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:128 msgid "" "Of course, instancing such imported scenes in other places manually works " "too." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121 -msgid "Materials" -msgstr "" - -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135 msgid "Location" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137 msgid "" "Godot supports materials in meshes or nodes. By default, materials will be " "put on each node." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:132 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:143 msgid "" "Materials can be stored within the scene or in external files. By default, " "they are stored in external files so editing them is possible. This is " @@ -14527,113 +14794,113 @@ msgid "" "in Godot." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:136 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 msgid "" "When materials are built-in, they will be lost each time the source scene is " "modified and re-imported." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:140 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:151 msgid "Keep on Reimport" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 msgid "" "Once materials are edited to use Godot features, the importer will keep the " "edited ones and ignore the ones coming from the source scene. This option is " "only present if materials are saved as files." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:147 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 msgid "Compress" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 msgid "" "Makes meshes use less precise numbers for multiple aspects of the mesh in " "order to save space." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "These are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164 msgid "" "Transform Matrix (Location, rotation, and scale) : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 msgid "" "Vertices : 32-bit float " "to 16-bit signed integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 msgid "" "Normals : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167 msgid "" "Tangents : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 msgid "" "Vertex Colors : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169 msgid "" "UV : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170 msgid "" "UV2 : 32-bit float " "to 32-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171 msgid "" "Vertex weights : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172 msgid "" "Armature bones : 32-bit float " "to 16-bit unsigned integer." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173 msgid "" "Array index : 32-bit or 16-" "bit unsigned integer based on how many elements there are." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "Additional info:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176 msgid "" "UV2 = The second UV channel for detail textures and baked lightmap textures." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 msgid "" "Array index = An array of numbers that number each element of the arrays " "above; i.e. they number the vertices and normals." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 msgid "" "In some cases, this might lead to loss of precision so disabling this option " "may be needed. For instance, if a mesh is very big or there are multiple " @@ -14642,15 +14909,15 @@ msgid "" "where they should be." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:174 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185 msgid "Meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188 msgid "Ensure Tangents" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 msgid "" "If textures with normalmapping are to be used, meshes need to have tangent " "arrays. This option ensures that these are generated if not present in the " @@ -14658,34 +14925,34 @@ msgid "" "them generated in the exporter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:187 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198 msgid "" "Meshes can be stored in separate files (resources) instead of built-in. This " "does not have much practical use unless one wants to build objects with them " "directly." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201 msgid "" "This option is provided to help those who prefer working directly with " "meshes instead of scenes." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:205 msgid "External Files" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207 msgid "" "Generated meshes and materials can be optionally stored in a subdirectory " "with the name of the scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:200 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:211 msgid "Animation Options" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213 msgid "" "Godot provides many options regarding how animation data is dealt with. Some " "exporters (such as Blender), can generate many animations in a single file. " @@ -14693,15 +14960,15 @@ msgid "" "timeline or, at worst, put each animation in a separate file." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:209 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220 msgid "Import of animations is enabled by default." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223 msgid "FPS" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225 msgid "" "Most 3D export formats store animation timeline in seconds instead of " "frames. To ensure animations are imported as faithfully as possible, please " @@ -14709,51 +14976,51 @@ msgid "" "result in minimal jitter." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:219 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230 msgid "Filter Script" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 msgid "" "It is possible to specify a filter script in a special syntax to decide " "which tracks from which animations should be kept. (@TODO this needs " "documentation)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 msgid "" "By default, animations are saved as built-in. It is possible to save them to " "a file instead. This allows adding custom tracks to the animations and " "keeping them after a reimport." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:243 msgid "Optimizer" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245 msgid "" "When animations are imported, an optimizer is run which reduces the size of " "the animation considerably. In general, this should always be turned on " "unless you suspect that an animation might be broken due to it being enabled." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 msgid "Clips" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251 msgid "" "It is possible to specify multiple animations from a single timeline as " "clips. Specify from which frame to which frame each clip must be taken (and, " "of course, don't forget to specify the FPS option above)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255 msgid "Scene Inheritance" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 msgid "" "In many cases, it may be desired to do modifications to the imported scene. " "By default, this is not possible because if the source asset changes " @@ -14761,102 +15028,102 @@ msgid "" "re-import the whole scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:249 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:260 msgid "" "It is possible, however, to do local modifications by using *Scene " "Inheritance*. Try to open the imported scene and the following dialog will " "appear:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265 msgid "In inherited scenes, the only limitations for modifications are:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 msgid "Nodes can't be removed (but can be added anywhere)." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 msgid "" "Sub-Resources can't be edited (save them externally as described above for " "this)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 msgid "Other than that, everything is allowed!" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273 msgid "Import Hints" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 msgid "" "Many times, when editing a scene, there are common tasks that need to be " "done after exporting:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:266 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 msgid "Adding collision detection to objects:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278 msgid "Setting objects as navigation meshes" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279 msgid "" "Deleting nodes that are not used in the game engine (like specific lights " "used for modelling)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 msgid "" "To simplify this workflow, Godot offers a few suffixes that can be added to " "the names of the objects in your 3D modelling software. When imported, Godot " "will detect them and perform actions automatically:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 msgid "Remove nodes (-noimp)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288 msgid "" "Node names that have this suffix will be removed at import time, no matter " "what their type is. They will not appear in the imported scene." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:292 msgid "Create collisions (-col, -colonly, -convcolonly)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294 msgid "" "Option \"-col\" will work only for Mesh nodes. If it is detected, a child " "static collision node will be added, using the same geometry as the mesh." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:297 msgid "" "However, it is often the case that the visual geometry is too complex or too " "un-smooth for collisions, which ends up not working well." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:289 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:300 msgid "" "To solve this, the \"-colonly\" modifier exists, which will remove the mesh " "upon import and create a :ref:`class_staticbody` collision instead. This " "helps the visual mesh and actual collision to be separated." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:293 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 msgid "" "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead " "of :ref:`class_concavepolygonshape`." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306 msgid "" "Option \"-colonly\" can be also used with Blender's empty objects. On import " "it will create a :ref:`class_staticbody` with collision node as a child. " @@ -14864,44 +15131,44 @@ msgid "" "Blender's empty draw type:" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:302 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 msgid "Single arrow will create :ref:`class_rayshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314 msgid "Cube will create :ref:`class_boxshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315 msgid "Image will create :ref:`class_planeshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316 msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318 msgid "" "For better visibility in Blender's editor user can set \"X-Ray\" option on " "collision empties and set some distinct color for them in User Preferences / " "Themes / 3D View / Empty." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:311 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322 msgid "Create navigatopm (-navmesh)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324 msgid "" "A mesh node with this suffix will be converted to a navigation mesh. " "Original Mesh node will be removed." msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:317 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:328 msgid "Rigid Body (-rigid)" msgstr "" -#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319 +#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330 msgid "Creates a rigid body from this mesh." msgstr "" @@ -16817,7 +17084,7 @@ msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:39 msgid "" -"**HUD**: Head's up display, or user interface. If the world moves, the life " +"**HUD**: Heads-up display, or user interface. If the world moves, the life " "counter, score, etc. must stay static." msgstr "" @@ -16842,8 +17109,8 @@ msgid "" "Viewport children will draw by default at layer \"0\", while a CanvasLayer " "will draw at any numeric layer. Layers with a greater number will be drawn " "above those with a smaller number. CanvasLayers also have their own " -"transform, and do not depend on the transform of other layers. This allows " -"the UI to be fixed in-place, while the world moves." +"transform and do not depend on the transform of other layers. This allows " +"the UI to be fixed in-place while the world moves." msgstr "" #: ../../docs/tutorials/2d/canvas_layers.rst:58 @@ -16878,7 +17145,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:9 msgid "" -"This tutorial is created after a topic that is a little dark for most users, " +"This tutorial is created after a topic that is a little dark for most users " "and explains all the 2D transforms going on for nodes from the moment they " "draw their content locally to the time they are drawn into the screen." msgstr "" @@ -16923,16 +17190,16 @@ msgstr "" msgid "" "Finally, viewports have a *Stretch Transform*, which is used when resizing " "or stretching the screen. This transform is used internally (as described " -"in :ref:`doc_multiple_resolutions`), but can also be manually set on each " +"in :ref:`doc_multiple_resolutions`) but can also be manually set on each " "viewport." msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:44 msgid "" "Input events received in the :ref:`MainLoop._input_event() " -"` callback are multiplied by this transform, " -"but lack the ones above. To convert InputEvent coordinates to local " -"CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() " +"` callback are multiplied by this transform but " +"lack the ones above. To convert InputEvent coordinates to local CanvasItem " +"coordinates, the :ref:`CanvasItem.make_input_local() " "` function was added for convenience." msgstr "" @@ -17028,7 +17295,7 @@ msgstr "" #: ../../docs/tutorials/2d/2d_transforms.rst:73 msgid "" -"Finally then, to convert a CanvasItem local coordinates to screen " +"Finally, then, to convert a CanvasItem local coordinates to screen " "coordinates, just multiply in the following order:" msgstr "" @@ -17157,7 +17424,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:83 msgid "" -"Finally, edit the polygon, this will give the tile a collision, and fix the " +"Finally, edit the polygon, this will give the tile a collision and fix the " "warning icon next to the CollisionPolygon node. **Remember to use snap!** " "Using snap will make sure collision polygons are aligned properly, allowing " "a character to walk seamlessly from tile to tile. Also **do not scale or " @@ -17297,7 +17564,7 @@ msgstr "" #: ../../docs/tutorials/2d/using_tilemaps.rst:182 msgid "" "You can use a single, separate image for each tile. This will remove all " -"artifacts, but can be more cumbersome to implement and is less optimized." +"artifacts but can be more cumbersome to implement and is less optimized." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4 @@ -17312,7 +17579,7 @@ msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9 msgid "" "Godot has nodes to draw sprites, polygons, particles, and all sorts of " -"stuff. For most cases this is enough, but not always. Before crying in fear, " +"stuff. For most cases this is enough but not always. Before crying in fear, " "angst, and rage because a node to draw that specific *something* does not " "exist... it would be good to know that it is possible to easily make any 2D " "node (be it :ref:`Control ` or :ref:`Node2D ` " @@ -17412,44 +17679,44 @@ msgid "" "something that Godot doesn't provide functions for. As an example, Godot " "provides a draw_circle() function that draws a whole circle. However, what " "about drawing a portion of a circle? You will have to code a function to " -"perform this, and draw it yourself." -msgstr "" - -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:152 -msgid "Arc function" +"perform this and draw it yourself." msgstr "" #: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:155 +msgid "Arc function" +msgstr "" + +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158 msgid "" "An arc is defined by its support circle parameters. That is: the center " -"position, and the radius. And the arc itself is then defined by the angle it " -"starts from, and the angle at which it stops. These are the 4 parameters we " -"have to provide to our drawing. We'll also provide the color value so we can " -"draw the arc in different colors if we wish." +"position and the radius. The arc itself is then defined by the angle it " +"starts from and the angle at which it stops. These are the 4 parameters that " +"we have to provide to our drawing. We'll also provide the color value, so we " +"can draw the arc in different colors if we wish." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:157 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:163 msgid "" "Basically, drawing a shape on screen requires it to be decomposed into a " -"certain number of points, linked from one to the following one. As you can " +"certain number of points linked from one to the following one. As you can " "imagine, the more points your shape is made of, the smoother it will appear, " -"but the heavier it will be, in terms of processing cost. In general, if your " -"shape is huge (or in 3D, close to the camera), it will require more points " -"to be drawn without it being angular-looking. On the contrary, if your shape " -"is small (or in 3D, far from the camera), you may reduce its number of " -"points to save processing costs. This is called *Level of Detail (LoD)*. In " -"our example, we will simply use a fixed number of points, no matter the " -"radius." +"but the heavier it will also be in terms of processing cost. In general, if " +"your shape is huge (or in 3D, close to the camera), it will require more " +"points to be drawn without it being angular-looking. On the contrary, if " +"your shape is small (or in 3D, far from the camera), you may reduce its " +"number of points to save processing costs. This is called *Level of Detail " +"(LoD)*. In our example, we will simply use a fixed number of points, no " +"matter the radius." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:191 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 msgid "" "Remember the number of points our shape has to be decomposed into? We fixed " "this number in the nb_points variable to a value of 32. Then, we initialize " "an empty PoolVector2Array, which is simply an array of Vector2." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:193 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207 msgid "" "The next step consists of computing the actual positions of these 32 points " "that compose an arc. This is done in the first for-loop: we iterate over the " @@ -17458,17 +17725,17 @@ msgid "" "the starting and ending angles." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:195 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:212 msgid "" "The reason why each angle is reduced by 90° is that we will compute 2D " "positions out of each angle using trigonometry (you know, cosine and sine " "stuff...). However, to be simple, cos() and sin() use radians, not degrees. " -"The angle of 0° (0 radian) starts at 3 o'clock, although we want to start " -"counting at 0 o'clock. So we reduce each angle by 90° in order to start " -"counting from 0 o'clock." +"The angle of 0° (0 radian) starts at 3 o'clock although we want to start " +"counting at 12 o'clock. So we reduce each angle by 90° in order to start " +"counting from 12 o'clock." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:197 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218 msgid "" "The actual position of a point located on a circle at angle 'angle' (in " "radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() " @@ -17480,7 +17747,7 @@ msgid "" "the PoolVector2Array which was previously defined." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:199 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:226 msgid "" "Now, we need to actually draw our points. As you can imagine, we will not " "simply draw our 32 points: we need to draw everything that is between each " @@ -17492,25 +17759,25 @@ msgid "" "happens, we simply would need to increase the number of points." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:202 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 msgid "Draw the arc on screen" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:203 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 msgid "" -"We now have a function that draws stuff on the screen: it is time to call in " +"We now have a function that draws stuff on the screen: It is time to call in " "the _draw() function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:229 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264 msgid "Result:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271 msgid "Arc polygon function" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272 msgid "" "We can take this a step further and not only write a function that draws the " "plain portion of the disc defined by the arc, but also its shape. The method " @@ -17518,61 +17785,61 @@ msgid "" "lines:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:275 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312 msgid "Dynamic custom drawing" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:276 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313 msgid "" "Alright, we are now able to draw custom stuff on screen. However, it is " -"static: let's make this shape turn around the center. The solution to do " +"static: Let's make this shape turn around the center. The solution to do " "this is simply to change the angle_from and angle_to values over time. For " "our example, we will simply increment them by 50. This increment value has " -"to remain constant, else the rotation speed will change accordingly." +"to remain constant or else the rotation speed will change accordingly." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:278 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:319 msgid "" "First, we have to make both angle_from and angle_to variables global at the " "top of our script. Also note that you can store them in other nodes and " "access them using get_node()." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:298 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:341 msgid "We make these values change in the _process(delta) function." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:300 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343 msgid "" "We also increment our angle_from and angle_to values here. However, we must " "not forget to wrap() the resulting values between 0 and 360°! That is, if " "the angle is 361°, then it is actually 1°. If you don't wrap these values, " -"the script will work correctly. But angle values will grow bigger and bigger " -"over time, until they reach the maximum integer value Godot can manage (2^31 " -"- 1). When this happens, Godot may crash or produce unexpected behavior. " -"Since Godot doesn't provide a wrap() function, we'll create it here, as it " -"is relatively simple." +"the script will work correctly, but the angle values will grow bigger and " +"bigger over time until they reach the maximum integer value Godot can manage " +"(2^31 - 1). When this happens, Godot may crash or produce unexpected " +"behavior. Since Godot doesn't provide a wrap() function, we'll create it " +"here, as it is relatively simple." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:302 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352 msgid "" "Finally, we must not forget to call the update() function, which " "automatically calls _draw(). This way, you can control when you want to " "refresh the frame." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:346 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:397 msgid "" "Also, don't forget to modify the _draw() function to make use of these " "variables:" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:370 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:421 msgid "" "Let's run! It works, but the arc is rotating insanely fast! What's wrong?" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:373 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424 msgid "" "The reason is that your GPU is actually displaying the frames as fast as it " "can. We need to \"normalize\" the drawing by this speed. To achieve, we have " @@ -17583,29 +17850,29 @@ msgid "" "the same speed on everybody's hardware." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:375 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:432 msgid "" "In our case, we simply need to multiply our 'rotation_ang' variable by " "'delta' in the _process() function. This way, our 2 angles will be increased " "by a much smaller value, which directly depends on the rendering speed." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:407 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:466 msgid "Let's run again! This time, the rotation displays fine!" msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:410 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469 #: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134 msgid "Tools" msgstr "工具" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:412 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471 msgid "" "Drawing your own nodes might also be desired while running them in the " -"editor, to use as preview or visualization of some feature or behavior." +"editor to use as a preview or visualization of some feature or behavior." msgstr "" -#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416 +#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:475 msgid "" "Remember to use the \"tool\" keyword at the top of the script (check the :" "ref:`doc_gdscript` reference if you forgot what this does)." @@ -17722,9 +17989,9 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:87 msgid "" -"The speed scale has a default value of ``1``, and is used to adjust the " -"speed of a particle system. Lowering the value will make the particles " -"slower, increasing the value will make the particles much faster." +"The speed scale has a default value of ``1`` and is used to adjust the speed " +"of a particle system. Lowering the value will make the particles slower " +"while increasing the value will make the particles much faster." msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:92 @@ -17733,8 +18000,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:94 msgid "" -"If lifetime is ``1`` and there are ten particles, it means a particle will " -"be emitted every 0.1 seconds. The explosiveness parameter changes this, and " +"If lifetime is ``1`` and there are 10 particles, it means a particle will be " +"emitted every 0.1 seconds. The explosiveness parameter changes this, and " "forces particles to be emitted all together. Ranges are:" msgstr "" @@ -17973,8 +18240,8 @@ msgstr "" #: ../../docs/tutorials/2d/particle_systems_2d.rst:279 msgid "" -"The variation value sets the initial hue variation applied to each particle. " -"The Variation rand value controls the hue variation randomness ratio." +"The Variation value sets the initial hue variation applied to each particle. " +"The Variation Rand value controls the hue variation randomness ratio." msgstr "" #: ../../docs/tutorials/2d/2d_movement.rst:4 @@ -18238,7 +18505,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:63 msgid "" "It is possible to create custom geometry by using the :ref:`Mesh " -"` resource directly, simply create your arrays and use the :ref:" +"` resource directly. Simply create your arrays and use the :ref:" "`Mesh.add_surface() ` function. A helper class is " "also available, :ref:`SurfaceTool `, which provides a " "more straightforward API and helpers for indexing, generating normals, " @@ -18286,7 +18553,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:99 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:9 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10 msgid "Environment" msgstr "" @@ -18424,7 +18691,7 @@ msgstr "" #: ../../docs/tutorials/3d/introduction_to_3d.rst:193 msgid "" -"Cameras are associated and only display to a parent or grand-parent " +"Cameras are associated with and only display to a parent or grandparent " "viewport. Since the root of the scene tree is a viewport, cameras will " "display on it by default, but if sub-viewports (either as render target or " "picture-in-picture) are desired, they need their own children cameras to " @@ -18457,10 +18724,6 @@ msgid "" "will take its place." msgstr "" -#: ../../docs/tutorials/3d/introduction_to_3d.rst:214 -msgid "Lights" -msgstr "" - #: ../../docs/tutorials/3d/introduction_to_3d.rst:216 msgid "" "There is no limitation on the number of lights nor of types of lights in " @@ -18893,16 +19156,16 @@ msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9 msgid "" "Godot follows a balanced performance philosophy. In performance world, there " -"are always trade-offs, which consist in trading speed for usability and " +"are always trade-offs which consist in trading speed for usability and " "flexibility. Some practical examples of this are:" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13 msgid "" "Rendering objects efficiently in high amounts is easy, but when a large " -"scene must be rendered it can become inefficient. To solve this, visibility " +"scene must be rendered, it can become inefficient. To solve this, visibility " "computation must be added to the rendering, which makes rendering less " -"efficient, but at the same time less objects are rendered, so efficiency " +"efficient, but, at the same time, less objects are rendered, so efficiency " "overall improves." msgstr "" @@ -18945,6 +19208,7 @@ msgid "" msgstr "" #: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:42 +#: ../../docs/tutorials/viewports/viewports.rst:175 msgid "Rendering" msgstr "" @@ -19268,8 +19532,8 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:57 msgid "" -"Godot has a more or less uniform cost per pixel (thanks to depth pre pass), " -"all lighting calculations are made by running the lighting shader on every " +"Godot has a more or less uniform cost per pixel (thanks to depth pre pass). " +"All lighting calculations are made by running the lighting shader on every " "pixel." msgstr "" @@ -19283,14 +19547,14 @@ msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:63 msgid "" -"Additionally, on low end or mobile devices, switching to vertex lighting can " +"Additionally, on low-end or mobile devices, switching to vertex lighting can " "considerably increase rendering performance." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:68 msgid "" -"Keep in mind that, when vertex lighting is enabled, only directional " -"lighting can produce shadows (for performance reasons)." +"Keep in mind that when vertex lighting is enabled, only directional lighting " +"can produce shadows (for performance reasons)." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:71 @@ -19322,67 +19586,67 @@ msgid "" "points can be sized (see below)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:88 +#: ../../docs/tutorials/3d/spatial_material.rst:89 msgid "World Triplanar" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:90 +#: ../../docs/tutorials/3d/spatial_material.rst:91 msgid "" "When using triplanar mapping (see below, in the UV1 and UV2 settings) " "triplanar is computed in object local space. This option makes triplanar " "work in world space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:94 +#: ../../docs/tutorials/3d/spatial_material.rst:95 msgid "Fixed Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:96 +#: ../../docs/tutorials/3d/spatial_material.rst:97 msgid "" "Makes the object rendered at the same size no matter the distance. This is, " "again, useful mostly for indicators (no depth test and high render priority) " "and some types of billboards." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:100 +#: ../../docs/tutorials/3d/spatial_material.rst:101 msgid "Do Not Receive Shadows" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:102 +#: ../../docs/tutorials/3d/spatial_material.rst:103 msgid "" "Makes the object not receive any kind of shadow that would otherwise be cast " "onto it." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:105 +#: ../../docs/tutorials/3d/spatial_material.rst:106 msgid "Vertex Color" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:107 +#: ../../docs/tutorials/3d/spatial_material.rst:108 msgid "" "This menu allows choosing what is done by default to vertex colors that come " "from your 3D modelling application. By default, they are ignored." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:112 +#: ../../docs/tutorials/3d/spatial_material.rst:114 msgid "Use as Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:114 +#: ../../docs/tutorials/3d/spatial_material.rst:116 msgid "Vertex color is used as albedo color." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:117 +#: ../../docs/tutorials/3d/spatial_material.rst:119 msgid "Is SRGB" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:119 +#: ../../docs/tutorials/3d/spatial_material.rst:121 msgid "" "Most 3D DCCs will likely export vertex colors as SRGB, so toggling this " "option on will help them look correct." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:124 +#: ../../docs/tutorials/3d/spatial_material.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:86 #: ../../docs/tutorials/platform/services_for_ios.rst:126 #: ../../docs/tutorials/platform/services_for_ios.rst:176 @@ -19391,334 +19655,334 @@ msgstr "" msgid "Parameters" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:126 +#: ../../docs/tutorials/3d/spatial_material.rst:128 msgid "" "SpatialMaterial also has several configurable parameters to tweak many " "aspects of the rendering:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:131 +#: ../../docs/tutorials/3d/spatial_material.rst:133 msgid "Diffuse Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:133 +#: ../../docs/tutorials/3d/spatial_material.rst:135 msgid "" "Specifies the algorithm used by diffuse scattering of light when hitting the " "object. The default one is Burley. Other modes are also available:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:136 +#: ../../docs/tutorials/3d/spatial_material.rst:138 msgid "" "**Burley:** Default mode, the original Disney Principled PBS diffuse " "algorithm." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:137 +#: ../../docs/tutorials/3d/spatial_material.rst:139 msgid "**Lambert:** Is not affected by roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:138 +#: ../../docs/tutorials/3d/spatial_material.rst:140 msgid "" "**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when " "roughness increases. Works great for hair and simulating cheap subsurface " "scattering. This implementation is energy conserving." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:139 +#: ../../docs/tutorials/3d/spatial_material.rst:141 msgid "" "**Oren Nayar:** This implementation aims to take microsurfacing into account " "(via roughness). Works well for clay-like materials and some types of cloth." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:140 +#: ../../docs/tutorials/3d/spatial_material.rst:142 msgid "" "**Toon:** Provides a hard cut for lighting, with smoothing affected by " "roughness." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:145 +#: ../../docs/tutorials/3d/spatial_material.rst:147 msgid "Specular Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:147 +#: ../../docs/tutorials/3d/spatial_material.rst:149 msgid "" "Specifies how the specular blob will be rendered. The specular blob " "represents the shape of a light source reflected in the object." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:149 -msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:150 -msgid "" -"**Blinn:** Common in previous-generation engines. Not worth using nowadays, " -"but left here for the sake of compatibility." -msgstr "" - #: ../../docs/tutorials/3d/spatial_material.rst:151 -msgid "**Phong:** Same as above." +msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:152 msgid "" -"**Toon:** Creates a toon blob, which changes size depending on roughness." +"**Blinn:** Common in previous-generation engines. Not worth using nowadays " +"but left here for the sake of compatibility." msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:153 +msgid "**Phong:** Same as above." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:154 +msgid "" +"**Toon:** Creates a toon blob, which changes size depending on roughness." +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:155 msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:159 +#: ../../docs/tutorials/3d/spatial_material.rst:161 msgid "Blend Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:161 +#: ../../docs/tutorials/3d/spatial_material.rst:163 msgid "" "Controls the blend mode for the material. Keep in mind that any mode other " "than Mix forces the object to go through transparent pipeline." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:163 +#: ../../docs/tutorials/3d/spatial_material.rst:165 msgid "Mix: Default blend mode, alpha controls how much the object is visible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:164 +#: ../../docs/tutorials/3d/spatial_material.rst:166 msgid "" "Add: Object is blended additively, nice for flares or some fire-like effects." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:165 +#: ../../docs/tutorials/3d/spatial_material.rst:167 msgid "Sub: Object is subtracted." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:166 +#: ../../docs/tutorials/3d/spatial_material.rst:168 msgid "Mul: Object is multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:171 +#: ../../docs/tutorials/3d/spatial_material.rst:173 msgid "Cull Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:173 +#: ../../docs/tutorials/3d/spatial_material.rst:175 msgid "" "Determines which side of the object is not drawn when back-faces are " "rendered:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:175 +#: ../../docs/tutorials/3d/spatial_material.rst:177 msgid "Back: Back of the object is culled when not visible (default)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:176 +#: ../../docs/tutorials/3d/spatial_material.rst:178 msgid "Front: Front of the object is culled when not visible" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:177 +#: ../../docs/tutorials/3d/spatial_material.rst:179 msgid "" "Disabled: Used for objects that are double sided (no culling is performed)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:180 +#: ../../docs/tutorials/3d/spatial_material.rst:182 msgid "Depth Draw Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:182 +#: ../../docs/tutorials/3d/spatial_material.rst:184 msgid "Specifies when depth rendering must take place." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:184 +#: ../../docs/tutorials/3d/spatial_material.rst:186 msgid "Opaque Only (default): Depth is only drawn for opaque objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:185 +#: ../../docs/tutorials/3d/spatial_material.rst:187 msgid "Always: Depth draw is drawn for both opaque and transparent objects" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:186 +#: ../../docs/tutorials/3d/spatial_material.rst:188 msgid "" "Never: No depth draw takes place (note: do not confuse with depth test " "option above)" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:187 +#: ../../docs/tutorials/3d/spatial_material.rst:189 msgid "" "Depth Pre-Pass: For transparent objects, an opaque pass is made first with " "the opaque parts, then transparency is drawn above. Use this option with " "transparent grass or tree foliage." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:193 +#: ../../docs/tutorials/3d/spatial_material.rst:195 msgid "Line Width" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:195 +#: ../../docs/tutorials/3d/spatial_material.rst:197 msgid "" "When drawing lines, specify the width of the lines being drawn. This option " "is not available in most modern hardware." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:198 +#: ../../docs/tutorials/3d/spatial_material.rst:200 msgid "Point Size" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:200 +#: ../../docs/tutorials/3d/spatial_material.rst:202 msgid "When drawing points, specify the point size in pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:203 +#: ../../docs/tutorials/3d/spatial_material.rst:205 msgid "Billboard Mode" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:205 +#: ../../docs/tutorials/3d/spatial_material.rst:207 msgid "" -"Enables billboard mode for drawing materials. This control how the object " +"Enables billboard mode for drawing materials. This controls how the object " "faces the camera:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:207 +#: ../../docs/tutorials/3d/spatial_material.rst:209 msgid "Disabled: Billboard mode is disabled" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:208 +#: ../../docs/tutorials/3d/spatial_material.rst:210 msgid "" "Enabled: Billboard mode is enabled, object -Z axis will always face the " "camera." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:209 +#: ../../docs/tutorials/3d/spatial_material.rst:211 msgid "Y-Billboard: Object X axis will always be aligned with the camera" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:210 +#: ../../docs/tutorials/3d/spatial_material.rst:212 msgid "" "Particles: When using particle systems, this type of billboard is best, " "because it allows specifying animation options." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:214 +#: ../../docs/tutorials/3d/spatial_material.rst:216 msgid "Above options are only enabled for Particle Billboard." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:217 +#: ../../docs/tutorials/3d/spatial_material.rst:219 msgid "Grow" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:219 +#: ../../docs/tutorials/3d/spatial_material.rst:221 msgid "Grows the object vertices in the direction pointed by their normals:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:223 +#: ../../docs/tutorials/3d/spatial_material.rst:225 msgid "" "This is commonly used to create cheap outlines. Add a second material pass, " -"make it black an unshaded, reverse culling (Cull Front), and add some grow:" -msgstr "" - -#: ../../docs/tutorials/3d/spatial_material.rst:230 -msgid "Use Alpha Scissor" +"make it black and unshaded, reverse culling (Cull Front), and add some grow:" msgstr "" #: ../../docs/tutorials/3d/spatial_material.rst:232 +msgid "Use Alpha Scissor" +msgstr "" + +#: ../../docs/tutorials/3d/spatial_material.rst:234 msgid "" "When transparency other than 0 or 1 is not needed, it's possible to set a " "threshold to avoid the object from rendering these pixels." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:236 +#: ../../docs/tutorials/3d/spatial_material.rst:238 msgid "" -"This renders the object via the opaque pipeline, which is faster and allows " +"This renders the object via the opaque pipeline which is faster and allows " "it to do mid and post process effects such as SSAO, SSR, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:239 +#: ../../docs/tutorials/3d/spatial_material.rst:241 msgid "Material colors, maps and channels" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:241 +#: ../../docs/tutorials/3d/spatial_material.rst:243 msgid "" "Besides the parameters, what defines materials themselves are the colors, " "textures and channels. Godot supports a extensive list of them. They will be " "described in detail below:" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:245 +#: ../../docs/tutorials/3d/spatial_material.rst:247 msgid "Albedo" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:247 +#: ../../docs/tutorials/3d/spatial_material.rst:249 msgid "" "Albedo is the base color for the material. Everything else works based on " "it. When set to *unshaded* this is the only color that is visible as-is. In " "previous versions of Godot, this channel was named *diffuse*. The change of " -"name mainly happens because, in PBR rendering, this color affects many more " +"name mainly happened because, in PBR rendering, this color affects many more " "calculations than just the diffuse lighting path." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:251 -msgid "Albedo color and texture can be used together, as they are multiplied." +#: ../../docs/tutorials/3d/spatial_material.rst:255 +msgid "Albedo color and texture can be used together as they are multiplied." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:253 +#: ../../docs/tutorials/3d/spatial_material.rst:257 msgid "" "*Alpha channel* in albedo color and texture is also used for the object " "transparency. If you use a color or texture with *alpha channel*, make sure " "to either enable transparency or *alpha scissoring* for it to work." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:257 +#: ../../docs/tutorials/3d/spatial_material.rst:262 msgid "Metallic" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:259 +#: ../../docs/tutorials/3d/spatial_material.rst:264 msgid "" -"Godot uses a Metallic model over competing models due to it's simplicity. " +"Godot uses a Metallic model over competing models due to its simplicity. " "This parameter pretty much defines how reflective the materials is. The more " "reflective it is, the least diffuse/ambient light and the more reflected " "light. This model is called \"energy conserving\"." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:262 +#: ../../docs/tutorials/3d/spatial_material.rst:269 msgid "" "The \"specular\" parameter here is just a general amount of for the " "reflectivity (unlike *metallic*, this one is not energy conserving, so " "simply leave it as 0.5 and don't touch it unless you need to)." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:264 +#: ../../docs/tutorials/3d/spatial_material.rst:273 msgid "" "The minimum internal reflectivity is 0.04, so (just like in real life) it's " "impossible to make a material completely unreflective." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:269 +#: ../../docs/tutorials/3d/spatial_material.rst:279 msgid "Roughness" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:271 +#: ../../docs/tutorials/3d/spatial_material.rst:281 msgid "" "Roughness affects mainly the way reflection happens. A value of 0 makes it a " -"perfect mirror, while a value of 1 completely blurs the reflection " +"perfect mirror while a value of 1 completely blurs the reflection " "(simulating the natural microsurfacing). Most common types of materials can " "be achieved from the right combination of *Metallic* and *Roughness*." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:277 +#: ../../docs/tutorials/3d/spatial_material.rst:288 msgid "Emission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:279 +#: ../../docs/tutorials/3d/spatial_material.rst:290 msgid "" "Emission specifies how much light is emitted by the material (keep in mind " "this does not do lighting on surrounding geometry unless GI Probe is used). " -"This value is just added to the resulting final image, and is not affected " -"by other lighting in the scene." +"This value is just added to the resulting final image and is not affected by " +"other lighting in the scene." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:287 +#: ../../docs/tutorials/3d/spatial_material.rst:299 msgid "Normalmap" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:289 +#: ../../docs/tutorials/3d/spatial_material.rst:301 msgid "" "Normal mapping allows to set a texture that represents finer shape detail. " "This does not modify geometry, just the incident angle for light. In Godot, " @@ -19726,11 +19990,11 @@ msgid "" "compatibility." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:295 +#: ../../docs/tutorials/3d/spatial_material.rst:308 msgid "Rim" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:297 +#: ../../docs/tutorials/3d/spatial_material.rst:310 msgid "" "Some fabrics have small micro fur that causes light to scatter around it. " "Godot emulates this with the *rim* parameter. Unlike other rim lighting " @@ -19739,30 +20003,30 @@ msgid "" "considerably more believable." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:302 +#: ../../docs/tutorials/3d/spatial_material.rst:317 msgid "" -"Rim size depends on roughness and there is a special parameter to specify " +"Rim size depends on roughness, and there is a special parameter to specify " "how it must be colored. If *tint* is 0, the color of the light is used for " "the rim. If *tint* is 1, then the albedo of the material is used. Using " "intermediate values generally works best." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:306 +#: ../../docs/tutorials/3d/spatial_material.rst:322 msgid "Clearcoat" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:308 +#: ../../docs/tutorials/3d/spatial_material.rst:324 msgid "" "The *clearcoat* parameter is used mostly to add a *secondary* pass of " "transparent coat to the material. This is common in car paint and toys. In " "practice, it's a smaller specular blob added on top of the existing material." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:312 +#: ../../docs/tutorials/3d/spatial_material.rst:329 msgid "Anisotropy" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:314 +#: ../../docs/tutorials/3d/spatial_material.rst:331 msgid "" "Changes the shape of the specular blow and aligns it to tangent space. " "Anisotropy is commonly used with hair, or to make materials such as brushed " @@ -19770,11 +20034,11 @@ msgid "" "flowmaps." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:321 +#: ../../docs/tutorials/3d/spatial_material.rst:339 msgid "Ambient Occlusion" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:323 +#: ../../docs/tutorials/3d/spatial_material.rst:341 msgid "" "In Godot's new PBR workflow, it is possible to specify a pre-baked ambient " "occlusion map. This map affects how much ambient light reaches each surface " @@ -19784,11 +20048,11 @@ msgid "" "possible." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:329 +#: ../../docs/tutorials/3d/spatial_material.rst:349 msgid "Depth" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:331 +#: ../../docs/tutorials/3d/spatial_material.rst:351 msgid "" "Setting a depth map to a material produces a ray-marched search to emulate " "the proper displacement of cavities along the view direction. This is not " @@ -19797,66 +20061,66 @@ msgid "" "results, *Depth* should be used together with normal mapping." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:337 +#: ../../docs/tutorials/3d/spatial_material.rst:359 msgid "Subsurface Scattering" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:339 +#: ../../docs/tutorials/3d/spatial_material.rst:361 msgid "" "This effect emulates light that goes beneath an object's surface, is " "scattered, and then comes out. It's useful to make realistic skin, marble, " "colored liquids, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:345 +#: ../../docs/tutorials/3d/spatial_material.rst:368 msgid "Transmission" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:347 +#: ../../docs/tutorials/3d/spatial_material.rst:370 msgid "" "Controls how much light from the lit side (visible to light) is transferred " "to the dark side (opposite side to light). This works well for thin objects " "such as tree/plant leaves, grass, human ears, etc." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:353 +#: ../../docs/tutorials/3d/spatial_material.rst:377 msgid "Refraction" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:355 +#: ../../docs/tutorials/3d/spatial_material.rst:379 msgid "" -"When refraction is enabled, it supersedes alpha blending and Godot attempts " +"When refraction is enabled, it supersedes alpha blending, and Godot attempts " "to fetch information from behind the object being rendered instead. This " "allows distorting the transparency in a way similar to refraction." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:361 +#: ../../docs/tutorials/3d/spatial_material.rst:386 msgid "Detail" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:363 +#: ../../docs/tutorials/3d/spatial_material.rst:388 msgid "" "Godot allows using secondary albedo and normal maps to generate a detail " "texture, which can be blended in many ways. Combining with secondary UV or " "triplanar modes, many interesting textures can be achieved." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:368 +#: ../../docs/tutorials/3d/spatial_material.rst:395 msgid "UV1 and UV2" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:370 +#: ../../docs/tutorials/3d/spatial_material.rst:397 msgid "" "Godot supports 2 UV channels per material. Secondary UV is often useful for " -"AO or Emission (baked light). UVs can be scaled and offseted, which is " -"useful in textures with repeat." +"AO or Emission (baked light). UVs can be scaled and offseted which is useful " +"in textures with repeat." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:373 +#: ../../docs/tutorials/3d/spatial_material.rst:401 msgid "Triplanar Mapping" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:375 +#: ../../docs/tutorials/3d/spatial_material.rst:403 msgid "" "Triplanar mapping is supported for both UV1 and UV2. This is an alternative " "way to obtain texture coordinates, often called \"Autotexture\". Textures " @@ -19864,38 +20128,38 @@ msgid "" "worldspace or object space." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:378 +#: ../../docs/tutorials/3d/spatial_material.rst:408 msgid "" "In the image below, you can see how all primitives share the same material " "with world triplanar, so bricks continue smoothly between them." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:383 +#: ../../docs/tutorials/3d/spatial_material.rst:414 msgid "Proximity and Distance Fade" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:385 +#: ../../docs/tutorials/3d/spatial_material.rst:416 msgid "" -"Godot allows materials to fade by proximity to another, as well as depending " -"on the distance to the viewer. Proximity fade is useful for effects such as " -"soft particles, or a mass of water with a smooth blending to the shores. " -"Distance fade is useful for light shafts or indicators that are only present " -"after a given distance." +"Godot allows materials to fade by proximity to each other as well as " +"depending on the distance to the viewer. Proximity fade is useful for " +"effects such as soft particles or a mass of water with a smooth blending to " +"the shores. Distance fade is useful for light shafts or indicators that are " +"only present after a given distance." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:389 +#: ../../docs/tutorials/3d/spatial_material.rst:420 msgid "" "Keep in mind enabling these enables alpha blending, so abusing them for a " "whole scene is not generally a good idea." msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:394 +#: ../../docs/tutorials/3d/spatial_material.rst:425 msgid "Render Priority" msgstr "" -#: ../../docs/tutorials/3d/spatial_material.rst:396 +#: ../../docs/tutorials/3d/spatial_material.rst:427 msgid "" -"Rendering order can be changed for objects, although this is mostly useful " +"Rendering order can be changed for objects although this is mostly useful " "for transparent objects (or opaque objects that do depth draw but no color " "draw, useful for cracks on the floor)." msgstr "" @@ -19906,13 +20170,13 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:9 msgid "" -"Lights emit light that mix with the materials and produces a visible result. " -"Light can come from several types of sources in a scene:" +"Lights emit light that mixes with the materials and produces a visible " +"result. Light can come from several types of sources in a scene:" msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:12 msgid "" -"From the Material itself, in the form of the emission color (though it does " +"From the Material itself in the form of the emission color (though it does " "not affect nearby objects unless baked)." msgstr "" @@ -19955,8 +20219,8 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:35 msgid "" -"**Energy**: Energy multiplier. This is useful to saturate lights or working " -"with :ref:`doc_high_dynamic_range`." +"**Energy**: Energy multiplier. This is useful for saturating lights or " +"working with :ref:`doc_high_dynamic_range`." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:36 @@ -19967,7 +20231,7 @@ msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:37 msgid "" -"**Negative**: Light becomes substractive instead of additive. It's sometimes " +"**Negative**: Light becomes subtractive instead of additive. It's sometimes " "useful to manually compensate some dark corners." msgstr "" @@ -19995,56 +20259,56 @@ msgid "" "function:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:47 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 msgid "**Enabled**: Check to enable shadow mapping in this light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:48 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 msgid "" "**Color**: Areas occluded are multiplied by this color. It is black by " "default, but it can be changed to tint shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:49 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 msgid "" "**Bias**: When this parameter is too small, self shadowing occurs. When too " "large, shadows separate from the casters. Tweak to what works best for you." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:50 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 msgid "" "**Contact**: Performs a short screen-space raycast to reduce the gap " "generated by the bias." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:51 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:52 msgid "" "**Reverse Cull Faces**: Some scenes work better when shadow mapping is " "rendered with face-culling inverted." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:53 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:54 msgid "" "Below is an image of how tweaking bias looks like. Default values work for " "most cases, but in general it depends on the size and complexity of geometry." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:57 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:59 msgid "Finally, if gaps can't be solved, the **Contact** option can help:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:61 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:63 msgid "" "Any sort of bias issues can always be fixed by increasing the shadow map " "resolution, although that may lead to decreased peformance on low-end " "hardware." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:64 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:67 msgid "Directional light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:66 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:69 msgid "" "This is the most common type of light and represents a light source very far " "away (such as the sun). It is also the cheapest light to compute and should " @@ -20052,26 +20316,26 @@ msgid "" "compute, but more on that later)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:70 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:73 msgid "" "Directional light models an infinite number of parallel light rays covering " -"the whole scene. The directional light node is represented by a big arrow, " +"the whole scene. The directional light node is represented by a big arrow " "which indicates the direction of the light rays. However, the position of " -"the node does not affect the lighting at all, and can be anywhere." +"the node does not affect the lighting at all and can be anywhere." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:77 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:80 msgid "" -"Every face whose front-side is hit by the light rays is lit, the others stay " -"dark. Most light types have specific parameters but directional lights are " -"pretty simple in nature so they don't." +"Every face whose front-side is hit by the light rays is lit while the others " +"stay dark. Most light types have specific parameters, but directional lights " +"are pretty simple in nature so they don't." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:81 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:84 msgid "Directional Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:83 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:86 msgid "" "To compute shadow maps, the scene is rendered (only depth) from an " "orthogonal point of view that covers the whole scene (or up to the max " @@ -20079,23 +20343,23 @@ msgid "" "closer to the camera receive blocky shadows." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:89 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:92 msgid "" "To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is " -"used. This splits the view frustum in 2 or 4 areas. Each area gets it's own " -"shadow map. This allows small, close areas to the viewer to have the same " +"used. This splits the view frustum in 2 or 4 areas. Each area gets its own " +"shadow map. This allows small areas close to the viewer to have the same " "shadow resolution as a huge, far-away area." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:94 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:97 msgid "With this, shadows become more detailed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:98 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:101 msgid "To control PSSM, a number of parameters are exposed:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:102 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 msgid "" "Each split distance is controlled relative to the camera far (or shadow " "**Max Distance** if greater than zero), so *0.0* is the eye position and " @@ -20104,129 +20368,128 @@ msgid "" "give more detail to close objects (like a character in a third person game)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:105 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:111 msgid "" "Always make sure to set a shadow *Max Distance* according to what the scene " "needs. The closer the max distance, the higher quality they shadows will " "have." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:107 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:114 msgid "" "Sometimes, the transition between a split and the next can look bad. To fix " -"this, the **\"Blend Splits\"** option can be turned on, which sacrifices " +"this, the **\"Blend Splits\"** option can be turned on which sacrifices " "detail in exchange for smoother transitions:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:112 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:120 msgid "" "The **\"Normal Bias\"** parameter can be used to fix special cases of self " "shadowing when objects are perpendicular to the light. The only downside is " "that it makes the shadow a bit thinner." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:117 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 msgid "" "The **\"Bias Split Scale\"** parameter can control extra bias for the splits " "that are far away. If self shadowing occurs only on the splits far away, " "this value can fix them." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:119 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:129 msgid "Finally, the **\"Depth Range\"** has two settings:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:121 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:131 msgid "" -"**Stable**: Keeps the shadow stable while the camera moves, the blocks that " -"appear in the outline when close to the shadow edges remain in-place. This " -"is the default and generally desired, but it reduces the effective shadow " -"resolution." +"**Stable**: Keeps the shadow stable while the camera moves, and the blocks " +"that appear in the outline when close to the shadow edges remain in-place. " +"This is the default and generally desired, but it reduces the effective " +"shadow resolution." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:122 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:132 msgid "" -"**Optimized**: Triest to achieve the maximum resolution available at any " +"**Optimized**: Tries to achieve the maximum resolution available at any " "given time. This may result in a \"moving saw\" effect on shadow edges, but " "at the same time the shadow looks more detailed (so this effect may be " "subtle enough to be forgiven)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:124 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:134 msgid "Just experiment which setting works better for your scene." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:126 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:136 msgid "" "Shadowmap size for directional lights can be changed in Project Settings -> " "Rendering -> Quality:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:130 -msgid "" -"Increasing it can solve bias problems, but reduce performance. Shadow " -"mapping is an art of tweaking." -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:133 -msgid "Omni light" -msgstr "" - -#: ../../docs/tutorials/3d/lights_and_shadows.rst:135 -msgid "" -"Omni light is a point source that emits light spherically in all directions " -"up to a given radius ." -msgstr "" - #: ../../docs/tutorials/3d/lights_and_shadows.rst:140 msgid "" -"In real life, light attenuation is an inverse function, which means omni " -"lights don't have a radius. This is a problem, because it means computing " -"several omni lights would become demanding." +"Increasing it can solve bias problems but reduce performance. Shadow mapping " +"is an art of tweaking." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:143 -msgid "" -"To solve this, a *Range* is introduced, together with an attenuation " -"function." +msgid "Omni light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:147 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:145 msgid "" -"These two parameters allow tweaking how this works visually, in order to " -"find aesthetically pleasing results." +"Omni light is a point source that emits light spherically in all directions " +"up to a given radius." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:150 +msgid "" +"In real life, light attenuation is an inverse function which means omni " +"lights don't have a radius. This is a problem because it means computing " +"several omni lights would become demanding." msgstr "" #: ../../docs/tutorials/3d/lights_and_shadows.rst:153 +msgid "" +"To solve this, a *Range* is introduced together with an attenuation function." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:157 +msgid "" +"These two parameters allow tweaking how this works visually in order to find " +"aesthetically pleasing results." +msgstr "" + +#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 msgid "Omni Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:155 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:165 msgid "" "Omni light shadow mapping is relatively straightforward. The main issue that " "needs to be considered is the algorithm used to render it." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:158 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 msgid "" "Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped" -"\"**. The former renders quickly but can cause deformations, while the later " +"\"**. The former renders quickly but can cause deformations while the later " "is more correct but more costly." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:163 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:174 msgid "" -"If the objects being renderer are mostly irregular, Dual Paraboloid is " +"If the objects being rendered are mostly irregular, Dual Paraboloid is " "usually enough. In any case, as these shadows are cached in a shadow atlas " "(more on that at the end), it may not make a difference in performance for " "most scenes." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:168 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 msgid "Spot light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:170 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:182 msgid "" "Spot lights are similar to omni lights, except they emit light only into a " "cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, " @@ -20234,111 +20497,111 @@ msgid "" "opposite direction it points to." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:177 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:189 msgid "" "Spot lights share the same **Range** and **Attenuation** as **OmniLight**, " "and add two extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:179 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:191 msgid "**Angle**: The aperture angle of the light" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:180 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 msgid "" "**Angle Attenuation**: The cone attenuation, which helps soften the cone " "borders." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:184 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:196 msgid "Spot Shadow Mapping" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:186 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:198 msgid "" "Spots don't need any parameters for shadow mapping. Keep in mind that, at " "more than 89 degrees of aperture, shadows stop functioning for spots, and " -"you should consider using an Omni light." +"you should consider using an Omni light instead." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:190 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:202 msgid "Shadow Atlas" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:192 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:204 msgid "" -"Unlike Directional lights, which have their own shadow texture, Omni and " -"Spot lights are assigned to slots of a shadow atlas. This atlas can be " -"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas." +"Unlike Directional lights which have their own shadow texture, Omni and Spot " +"lights are assigned to slots of a shadow atlas. This atlas can be configured " +"in Project Settings -> Rendering -> Quality -> Shadow Atlas." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:197 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:209 msgid "" "The resolution applies to the whole Shadow Atlas. This atlas is divided in " "four quadrants:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:201 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:213 msgid "" -"Each quadrant, can be subdivided to allocate any number of shadow maps, " +"Each quadrant can be subdivided to allocate any number of shadow maps. The " "following is the default subdivision:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:205 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:217 msgid "" -"The allocation logic is simple, the biggest shadow map size (when no " +"The allocation logic is simple. The biggest shadow map size (when no " "subdivision is used) represents a light the size of the screen (or bigger). " "Subdivisions (smaller maps) represent shadows for lights that are further " "away from view and proportionally smaller." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:208 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 msgid "Every frame, the following logic is done for all lights:" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:210 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:224 msgid "" -"Check if the light is on a slot of the right size, if not, re-render it and " +"Check if the light is on a slot of the right size. If not, re-render it and " "move it to a larger/smaller slot." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:211 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:225 msgid "" -"Check if any object affecting the shadow map has changed, if it did, re-" +"Check if any object affecting the shadow map has changed. If it did, re-" "render the light." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:212 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 msgid "" -"If neither of the above has happened, nothing is done and the shadow is left " -"untouched." +"If neither of the above has happened, nothing is done, and the shadow is " +"left untouched." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:214 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:228 msgid "" "If the slots in a quadrant are full, lights are pushed back to smaller slots " "depending on size and distance." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:216 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:230 msgid "" "This allocation strategy works for most games, but you may to use a separate " "one in some cases (as example, a top-down game where all lights are around " "the same size and quadrands may have all the same subdivision)." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:220 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:234 msgid "Shadow Filter Quality" msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:222 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:236 msgid "" "The filter quality of shadows can be tweaked. This can be found in Project " "Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 " "and PCF13." msgstr "" -#: ../../docs/tutorials/3d/lights_and_shadows.rst:226 +#: ../../docs/tutorials/3d/lights_and_shadows.rst:242 msgid "It affects the blockyness of the shadow outline:" msgstr "" @@ -20368,61 +20631,62 @@ msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:17 msgid "" -"They are efficient to render, but expensive to compute. This leads to a " -"default behavior where they only capture on scene load." +"They are efficient to render but expensive to compute. This leads to a " +"default" msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:18 msgid "" -"They work best for rectangular shaped rooms or places, otherwise the " -"reflections shown are not as faithful (especially when roughness is 0)." -msgstr "" - -#: ../../docs/tutorials/3d/reflection_probes.rst:21 -#: ../../docs/tutorials/3d/gi_probes.rst:27 -#: ../../docs/tutorials/3d/baked_lightmaps.rst:32 -msgid "Setting Up" +"behavior where they only capture on scene load. * They work best for " +"rectangular shaped rooms or places, otherwise the reflections shown are not " +"as faithful (especially when roughness is 0)." msgstr "" #: ../../docs/tutorials/3d/reflection_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:32 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:41 +msgid "Setting Up" +msgstr "" + +#: ../../docs/tutorials/3d/reflection_probes.rst:25 msgid "" -"Create a ReflectionProbe node, and wrap it around the area where you want to " +"Create a ReflectionProbe node and wrap it around the area where you want to " "have reflections:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:27 +#: ../../docs/tutorials/3d/reflection_probes.rst:29 msgid "" "This should result in immediate local reflections. If you are using a Sky " "texture, reflections are by default blended with it." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:29 +#: ../../docs/tutorials/3d/reflection_probes.rst:32 msgid "" "By default, on interiors, reflections may appear to not have much " "consistence. In this scenario, make sure to tick the *\"Box Correct\"* " "property." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:34 +#: ../../docs/tutorials/3d/reflection_probes.rst:38 msgid "" "This setting changes the reflection from an infinite skybox to reflecting a " "box the size of the probe:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:38 +#: ../../docs/tutorials/3d/reflection_probes.rst:43 msgid "" "Adjusting the box walls may help improve the reflection a bit, but it will " "always look the best in box shaped rooms." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:40 +#: ../../docs/tutorials/3d/reflection_probes.rst:46 msgid "" "The probe captures the surrounding from the center of the gizmo. If, for " "some reason, the room shape or contents occlude the center, it can be " "displaced to an empty place by moving the handles in the center:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:45 +#: ../../docs/tutorials/3d/reflection_probes.rst:52 msgid "" "By default, shadow mapping is disabled when rendering probes (only in the " "rendered image inside the probe, not the actual scene). This is a simple way " @@ -20430,7 +20694,7 @@ msgid "" "can be toggled on/off with the *Enable Shadow* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:50 +#: ../../docs/tutorials/3d/reflection_probes.rst:59 msgid "" "Finally, keep in mind that you may not want the Reflection Probe to render " "some objects. A typical scenario is an enemy inside the room which will move " @@ -20438,42 +20702,42 @@ msgid "" "*Cull Mask* setting:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:56 -#: ../../docs/tutorials/3d/gi_probes.rst:72 +#: ../../docs/tutorials/3d/reflection_probes.rst:67 +#: ../../docs/tutorials/3d/gi_probes.rst:85 msgid "Interior vs Exterior" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:58 +#: ../../docs/tutorials/3d/reflection_probes.rst:69 msgid "" "If you are using reflection probes in an interior setting, it is recommended " -"that the **Interior** property is enabled. This makes the probe not render " -"the sky, and also allows custom ambient lighting settings." +"that the **Interior** property is enabled. This stops the probe from " +"rendering the sky and also allows custom ambient lighting settings." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:63 +#: ../../docs/tutorials/3d/reflection_probes.rst:75 msgid "" "When probes are set to **Interior**, custom constant ambient lighting can be " "specified per probe. Just choose a color and an energy." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:65 +#: ../../docs/tutorials/3d/reflection_probes.rst:78 msgid "" "Optionally, you can blend this ambient light with the probe diffuse capture " "by tweaking the **Ambient Contribution** property (0.0 means, pure ambient " "color, while 1.0 means pure diffuse capture)." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:69 +#: ../../docs/tutorials/3d/reflection_probes.rst:84 msgid "Blending" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:71 +#: ../../docs/tutorials/3d/reflection_probes.rst:86 msgid "" -"Multiple reflection probes can be used and Godot will blend them where they " +"Multiple reflection probes can be used, and Godot will blend them where they " "overlap using a smart algorithm:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:75 +#: ../../docs/tutorials/3d/reflection_probes.rst:90 msgid "" "As you can see, this blending is never perfect (after all, these are box " "reflections, not real reflections), but these artifacts are only visible " @@ -20481,31 +20745,31 @@ msgid "" "mapping and varying levels of roughness which can hide this." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:79 +#: ../../docs/tutorials/3d/reflection_probes.rst:96 msgid "" "Alternatively, Reflection Probes work well blended together with Screen " "Space Reflections to solve these problems. Combining them makes local " -"reflections appear more faithful, while probes only used as fallback when no " -"screen-space information is found:" +"reflections appear more faithful while probes are only used as fallback when " +"no screen-space information is found:" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:84 +#: ../../docs/tutorials/3d/reflection_probes.rst:102 msgid "" -"Finally, blending interior and exterior probes is a recommended approach " +"Finally, blending interior and exterior probes is the recommended approach " "when making levels that combine both interiors and exteriors. Near the door, " -"a probe can be marked as *exterior* (so it will get sky reflections), while " -"on the inside it can be interior." +"a probe can be marked as *exterior* (so it will get sky reflections) while " +"on the inside, it can be interior." msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:88 +#: ../../docs/tutorials/3d/reflection_probes.rst:107 msgid "Reflection Atlas" msgstr "" -#: ../../docs/tutorials/3d/reflection_probes.rst:90 +#: ../../docs/tutorials/3d/reflection_probes.rst:109 msgid "" -"In the current renderer implementation, all probes are the same size and " -"they are fit into a Reflection Atlas. The size and amount of probes can be " -"customized in Project Settings -> Quality -> Reflections" +"In the current renderer implementation, all probes are the same size and are " +"fit into a Reflection Atlas. The size and amount of probes can be customized " +"in Project Settings -> Quality -> Reflections" msgstr "" #: ../../docs/tutorials/3d/gi_probes.rst:4 @@ -20520,186 +20784,186 @@ msgid "" "complex technique to produce indirect light and reflections." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:12 +#: ../../docs/tutorials/3d/gi_probes.rst:14 msgid "" -"The strength of GI Probes are real-time, high quality, indirect light. While " +"The strength of GI Probes is real-time, high quality, indirect light. While " "the scene needs a quick pre-bake for the static objects that will be used, " -"lights can be added, changed or removed and this will be updated in real-" +"lights can be added, changed or removed, and this will be updated in real-" "time. Dynamic objects that move within one of these probes will also receive " "indirect lighting from the scene automatically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:16 +#: ../../docs/tutorials/3d/gi_probes.rst:20 msgid "" "Just like with ReflectionProbe, GIProbes can be blended (in a bit more " "limited way), so it is possible to provide full real-time lighting for a " "stage without having to resort to lightmaps." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:19 +#: ../../docs/tutorials/3d/gi_probes.rst:24 msgid "The main downside of GIProbes are:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:21 +#: ../../docs/tutorials/3d/gi_probes.rst:26 msgid "" "A small amount of light leaking can occur if the level is not carefully " -"designed. this must be artist-tweaked." +"designed. This must be artist-tweaked." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:22 +#: ../../docs/tutorials/3d/gi_probes.rst:27 msgid "" "Performance requirements are higher than for lightmaps, so it may not run " -"properly in low end integrated GPUs (may need to reduce resolution)." +"properly in low-end integrated GPUs (may need to reduce resolution)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:23 +#: ../../docs/tutorials/3d/gi_probes.rst:28 msgid "" "Reflections are voxelized, so they don't look as sharp as with " -"ReflectionProbe, but in exchange they are volumetric so any room size or " -"shape works for them. Mixing them with Screen Space Reflection also works " +"ReflectionProbe. However, in exchange they are volumetric, so any room size " +"or shape works for them. Mixing them with Screen Space Reflection also works " "well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:24 +#: ../../docs/tutorials/3d/gi_probes.rst:29 msgid "" "They consume considerably more video memory than Reflection Probes, so they " "must be used by care in the right subdivision sizes." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:29 +#: ../../docs/tutorials/3d/gi_probes.rst:34 msgid "" "Just like a ReflectionProbe, simply set up the GIProbe by wrapping it around " "the geometry that will be affected." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:33 +#: ../../docs/tutorials/3d/gi_probes.rst:39 msgid "" "Afterwards, make sure to enable the geometry will be baked. This is " "important in order for GIPRobe to recognize objects, otherwise they will be " "ignored:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:37 +#: ../../docs/tutorials/3d/gi_probes.rst:44 msgid "" "Once the geometry is set-up, push the Bake button that appears on the 3D " "editor toolbar to begin the pre-baking process:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:42 +#: ../../docs/tutorials/3d/gi_probes.rst:50 msgid "Adding Lights" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:44 +#: ../../docs/tutorials/3d/gi_probes.rst:52 msgid "" "Unless there are materials with emission, GIProbe does nothing by default. " "Lights need to be added to the scene to have an effect." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:46 +#: ../../docs/tutorials/3d/gi_probes.rst:55 msgid "" "The effect of indirect light can be viewed quickly (it is recommended you " -"turn off all ambient/sky lighting to tweak this, though as in the picture):" +"turn off all ambient/sky lighting to tweak this, though, as shown below):" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:50 +#: ../../docs/tutorials/3d/gi_probes.rst:60 msgid "" "In some situations, though, indirect light may be too weak. Lights have an " "indirect multiplier to tweak this:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:54 +#: ../../docs/tutorials/3d/gi_probes.rst:65 msgid "" "And, as GIPRobe lighting updates in real-time, this effect is immediate:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:59 +#: ../../docs/tutorials/3d/gi_probes.rst:70 msgid "Reflections" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:61 +#: ../../docs/tutorials/3d/gi_probes.rst:72 msgid "" "For materials with high metalness and low roughness, it's possible to " "appreciate voxel reflections. Keep in mind that these have far less detail " -"than Reflection Probes or Screen Space Reflections, but fully reflect " +"than Reflection Probes or Screen Space Reflections but fully reflect " "volumetrically." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:66 +#: ../../docs/tutorials/3d/gi_probes.rst:78 msgid "" "GIProbes can easily be mixed with Reflection Probes and Screen Space " "Reflections, as a full 3-stage fallback-chain. This allows to have precise " "reflections where needed:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:74 +#: ../../docs/tutorials/3d/gi_probes.rst:87 msgid "" "GI Probes normally allow mixing with lighting from the sky. This can be " "disabled when turning on the *Interior* setting." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:78 +#: ../../docs/tutorials/3d/gi_probes.rst:92 msgid "" "The difference becomes clear in the image below, where light from the sky " "goes from spreading inside to being ignored." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:82 +#: ../../docs/tutorials/3d/gi_probes.rst:97 msgid "" "As complex buildings may mix interiors with exteriors, combining GIProbes " "for both parts works well." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:86 +#: ../../docs/tutorials/3d/gi_probes.rst:102 msgid "Tweaking" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:88 +#: ../../docs/tutorials/3d/gi_probes.rst:104 msgid "GI Probes support a few parameters for tweaking:" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:92 +#: ../../docs/tutorials/3d/gi_probes.rst:108 msgid "" "**Subdiv** Subdivision used for the probe. The default (128) is generally " "good for small to medium size areas. Bigger subdivisions use more memory." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:93 -msgid "**Extents** Size of the probe, can be tweaked from the gizmo." +#: ../../docs/tutorials/3d/gi_probes.rst:109 +msgid "**Extents** Size of the probe. Can be tweaked from the gizmo." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:94 +#: ../../docs/tutorials/3d/gi_probes.rst:110 msgid "" "**Dynamic Range** Maximum light energy the probe can absorb. Higher values " "allow brighter light, but with less color detail." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:95 +#: ../../docs/tutorials/3d/gi_probes.rst:111 msgid "" "**Energy** Multiplier for all the probe. Can be used to make the indirect " "light brighter (although it's better to tweak this from the light itself)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:96 +#: ../../docs/tutorials/3d/gi_probes.rst:112 msgid "**Propagation** How much light propagates through the probe internally." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:97 +#: ../../docs/tutorials/3d/gi_probes.rst:113 msgid "" "**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, " "should generally be above 1.0 (1==voxel size)." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:98 +#: ../../docs/tutorials/3d/gi_probes.rst:114 msgid "" "**Normal Bias** Alternative type of bias useful for some scenes. Experiment " "with this one if regular bias does not work." msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:102 +#: ../../docs/tutorials/3d/gi_probes.rst:118 msgid "Quality" msgstr "" -#: ../../docs/tutorials/3d/gi_probes.rst:104 +#: ../../docs/tutorials/3d/gi_probes.rst:120 msgid "" "GIProbes are quite demanding. It is possible to use lower quality voxel cone " "tracing in exchange of more performance." @@ -20713,38 +20977,38 @@ msgstr "" msgid "" "Baked lightmaps are an alternative workflow for adding indirect (or baked) " "lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked " -"lightmaps work fine on low end PCs and mobile devices as they consume almost " +"lightmaps work fine on low-end PCs and mobile devices as they consume almost " "no resources in run-time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:12 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:14 msgid "" -"Unlike GIProbes, Baked Lightmaps are completely static, once baked they " +"Unlike GIProbes, Baked Lightmaps are completely static. Once baked they " "can't be modified at all. They also don't provide the scene with " "reflections, so using :ref:`doc_reflection_probes` together with it on " "interiors (or using a Sky on exteriors) is a requirement to get good quality." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:16 -msgid "" -"As they are baked, they have less problems regarding to light bleeding than " -"GIProbe and indirect light can look better if using Raytrace mode on high " -"quality setting (but baking can take a while to bake)." -msgstr "" - #: ../../docs/tutorials/3d/baked_lightmaps.rst:19 msgid "" -"In the end, deciding which indirect lighting approach is better depends on " -"your use case. In general GIProbe looks better and is much easier to set " -"upt. For low end compatibility or mobile, though, Baked Lightmaps are your " -"only choice." +"As they are baked, they have less problems regarding to light bleeding than " +"GIProbe, and indirect light can look better if using Raytrace mode on high " +"quality setting (but baking can take a while)." msgstr "" #: ../../docs/tutorials/3d/baked_lightmaps.rst:23 +msgid "" +"In the end, deciding which indirect lighting approach is better depends on " +"your use case. In general, GIProbe looks better and is much easier to set " +"up. For low-end compatibility or mobile, though, Baked Lightmaps are your " +"only choice." +msgstr "" + +#: ../../docs/tutorials/3d/baked_lightmaps.rst:29 msgid "Visual Comparison" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:25 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:31 msgid "" "Here are some comparisons of how Baked Lightmaps vs GIProbe look. Notice " "that lightmaps are more accurate, but also suffer from the fact that " @@ -20753,44 +21017,44 @@ msgid "" "more smooth overall." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:34 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:43 msgid "" -"First of all, before the lightmapper can do anything, objects to be baked " -"need an UV2 layer and a texture size. An UV2 layer is a set of secondary " -"texture coordinates that ensures any face in the object has it's own place " -"in the UV map. Faces must not share pixels in the texture." +"First of all, before the lightmapper can do anything, the objects to be " +"baked need an UV2 layer and a texture size. An UV2 layer is a set of " +"secondary texture coordinates that ensures any face in the object has its " +"own place in the UV map. Faces must not share pixels in the texture." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:37 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:48 msgid "" "There are a few ways to ensure your object has a unique UV2 layer and " "texture size" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:40 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:51 msgid "Unwrap from your 3D DCC" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:42 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:53 msgid "" "One option is to do it from your favorite 3D app. This approach is generally " -"not recommended but it's explained first so you know it exists. The main " -"advantage is that, on complex objects that you may want to re-import a lot, " -"the texture generation process can be quite costly within Godot, so having " -"it unwrapped before import can be faster." +"not recommended, but it's explained first so that you know it exists. The " +"main advantage is that, on complex objects that you may want to re-import a " +"lot, the texture generation process can be quite costly within Godot, so " +"having it unwrapped before import can be faster." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:46 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:59 msgid "Simply do an unwrap on the second UV2 layer." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:50 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:63 msgid "" "And import normally. Remember you will need to set the texture size on the " "mesh after import." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:54 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:68 msgid "" "If you use external meshes on import, the size will be kept. Be wary that " "most unwrappers in 3D DCCs are not quality oriented, as they are meant to " @@ -20798,27 +21062,27 @@ msgid "" "better unwrapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:58 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 msgid "Unwrap from within Godot" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:60 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:76 msgid "" "Godot has an option to unwrap meshes and visualize the UV channels. It can " "be found in the Mesh menu:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:64 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:81 msgid "" -"This will generate a second set of UV2 coordinates, which can be used for " -"baking and it will set the texture size automatically." +"This will generate a second set of UV2 coordinates which can be used for " +"baking, and it will also set the texture size automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:67 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 msgid "Unwrap on Scene import" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:69 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:87 msgid "" "This is probably the best approach overall. The only downside is that, on " "large models, unwrap can take a while on import. Just select the imported " @@ -20826,7 +21090,7 @@ msgid "" "following option can be modified:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:74 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:94 msgid "" "The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel " "size in world units must also be provided, as this will determine the final " @@ -20834,13 +21098,13 @@ msgid "" "map)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:77 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:98 msgid "" "The effect of setting this option is that all meshes within the scene will " "have their UV2 maps properly generated." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:79 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:101 msgid "" "As a word of warning: When reusing a mesh within a scene, keep in mind that " "UVs will be generated for the first instance found. If the mesh is re-used " @@ -20849,113 +21113,113 @@ msgid "" "source mesh at different scales if you are planning to use lightmapping." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:83 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 msgid "Checking UV2" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:85 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 msgid "" "In the mesh menu mentioned before, the UV2 texture coordinates can be " "visualized. Make sure, if something is failing, to check that the meshes " "have these UV2 coordinates:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:90 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:116 msgid "Setting up the Scene" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:92 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:118 msgid "" "Before anything is done, a **BakedLight** Node needs to be added to a scene. " "This will enable light baking on all nodes (and sub-nodes) in that scene, " "even on instanced scenes." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:96 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:124 msgid "" "A sub-scene can be instanced several times, as this is supported by the " -"baker and each will be assigned a lightmap of it's own (just make sure to " +"baker, and each will be assigned a lightmap of its own (just make sure to " "respect the rule about scaling mentioned before):" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:100 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 msgid "Configure Bounds" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:102 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:132 msgid "" -"Lightmap needs an approximate volume of the area affected, because it uses " -"it to transfer light to dynamic objects inside (more on that later). Just " -"cover the scene with the volume, as you do with GIProbe:" +"Lightmap needs an approximate volume of the area affected because it uses it " +"to transfer light to dynamic objects inside (more on that later). Just cover " +"the scene with the volume as you do with GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:108 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:139 msgid "Setting Up Meshes" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:110 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:141 msgid "" "For a **MeshInstance** node to take part in the baking process, it needs to " "have the \"Use in Baked Light\" property enabled." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:114 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:146 msgid "" "When auto-generating lightmaps on scene import, this is enabled " "automatically." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:117 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:149 msgid "Setting up Lights" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:119 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:151 msgid "" "Lights are baked with indirect light by default. This means that " "shadowmapping and lighting are still dynamic and affect moving objects, but " "light bounces from that light will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:122 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:155 msgid "" -"Lights can be disabled (no bake), or be fully baked (direct and indirect), " -"this can be controlled from the **Bake Mode** menu in lights:" +"Lights can be disabled (no bake) or be fully baked (direct and indirect). " +"This can be controlled from the **Bake Mode** menu in lights:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:126 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:160 msgid "The modes are :" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:128 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:162 msgid "" "**Disabled:** Light is ignored in baking. Keep in mind hiding a light will " "have no effect for baking, so this must be used instead." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:129 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 msgid "" -"**Indirect:** This is the default mode, only indirect lighting will be baked." +"**Indirect:** This is the default mode. Only indirect lighting will be baked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:130 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:164 msgid "" "**All:** Both indirect and direct lighting will be baked. If you don't want " "the light to appear twice (dynamically and statically), simply hide it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:133 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 msgid "Baking Quality" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:135 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 msgid "" "BakedLightmap uses, for simplicity, a voxelized version of the scene to " "compute lighting. Voxel size can be adjusted with the **Bake Subdiv** " -"parameter. More subdivision results in more detail, but also takes more time " +"parameter. More subdivision results in more detail but also takes more time " "to bake." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:138 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 msgid "" "In general, the defaults are good enough. There is also a **Capture " "Subdivision** (that must always be equal or less to the main subdivision), " @@ -20963,110 +21227,110 @@ msgid "" "It's default value is also good enough for more cases." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:143 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:180 msgid "" "Besides the capture size, quality can be modified by setting the **Bake " "Mode**. Two modes of capturing indirect are provided:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:147 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:185 msgid "" -"**Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look " -"similar (but slightly better) to GIProbe." +"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. " +"Looks similar (but slightly better) to GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:148 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:186 msgid "" -"**Ray Tracing**: This method is more precise, but can take considerably " +"**Ray Tracing**: This method is more precise but can take considerably " "longer to bake. If used in low or medium quality, some scenes may produce " "grain." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:152 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:190 msgid "Baking" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:154 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:192 msgid "" "To begin the bake process, just push the big **Bake Lightmaps** button on " -"top, when selecting the BakedLightmap node:" +"top when selecting the BakedLightmap node:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:158 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:197 msgid "" "This can take from seconds to minutes (or hours) depending on scene size, " "bake method and quality selected." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:161 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:201 msgid "Configuring Bake" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:163 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:203 msgid "Several more options are present for baking:" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:165 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:205 msgid "" "**Bake Subdiv**: Godot lightmapper uses a grid to transfer light information " "around. The default value is fine and should work for most cases. Increase " "it in case you want better lighting on small details or your scene is large." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:166 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:206 msgid "" "**Capture Subdiv**: This is the grid used for real-time capture information " "(lighting dynamic objects). Default value is generally OK, it's usually " "smaller than Bake Subdiv and can't be larger than it." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:167 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:207 msgid "" "**Bake Quality**: Three bake quality modes are provided, Low, Medium and " -"High. Each takes less and more time." +"High. Higher quality takes more time." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:168 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:208 msgid "" "**Bake Mode**: The baker can use two different techniques: *Voxel Cone " "Tracing* (fast but approximate), or *RayTracing* (slow, but accurate)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:169 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:209 msgid "" -"**Propagation**: Used for the *Voxel Cone Trace* mode, works just like in " +"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in " "GIProbe." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:170 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:210 msgid "" "**HDR**: If disabled, lightmaps are smaller but can't capture any light over " "white (1.0)." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:171 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:211 msgid "" "**Image Path**: Where lightmaps will be saved. By default, on the same " "directory as the scene (\".\"), but can be tweaked." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:172 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:212 msgid "**Extents**: Size of the area affected (can be edited visually)" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:173 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:213 msgid "" "**Light Data**: Contains the light baked data after baking. Textures are " -"saved to disk, but this also contains the capture data for dynamic objects, " -"which can be a bit heavy. If you are using .tscn formats (instead of .scn) " +"saved to disk, but this also contains the capture data for dynamic objects " +"which can be a bit heavy. If you are using .tscn formats (instead of .scn), " "you can save it to disk." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:177 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:217 msgid "Dynamic Objects" msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:179 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:219 msgid "" "In other engines or lightmapper implementations, you are required to " "manually place small objects called \"lightprobes\" all around the level to " @@ -21074,12 +21338,12 @@ msgid "" "dynamic objects that move around the scene." msgstr "" -#: ../../docs/tutorials/3d/baked_lightmaps.rst:181 +#: ../../docs/tutorials/3d/baked_lightmaps.rst:224 msgid "" -"This implementation of lightmapping uses a different method, so this process " -"is automatic and you don't have to do anything. Just move your objects " -"around and they will be lit accordingly. Of course, you have to make sure " -"you set up your scene bounds accordingly or it won't work." +"However, this implementation of lightmapping uses a different method. The " +"process is automatic, so you don't have to do anything. Just move your " +"objects around, and they will be lit accordingly. Of course, you have to " +"make sure you set up your scene bounds accordingly or it won't work." msgstr "" #: ../../docs/tutorials/3d/environment_and_post_processing.rst:4 @@ -21092,213 +21356,213 @@ msgid "" "post-processing system with many available effects right out of the box." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:11 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12 msgid "" "The Environment resource stores all the information required for controlling " "rendering environment. This includes sky, ambient lighting, tone mapping, " -"effects and adjustments. By itself it does nothing, but it becomes enabled " -"once used in one of the following locations, in order of priority:" +"effects, and adjustments. By itself it does nothing, but it becomes enabled " +"once used in one of the following locations in order of priority:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:15 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18 msgid "Camera Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:17 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20 msgid "" "An Environment can be set to a camera. It will have priority over any other " "setting." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:21 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24 msgid "" "This is mostly useful when wanting to override an existing environment, but " "in general it's a better idea to use the option below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:25 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:29 msgid "WorldEnvironment Node" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:27 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 msgid "" "The WorldEnvironment node can be added to any scene, but only one can exist " "per active scene tree. Adding more than one will result in a warning." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:36 msgid "" "Any Environment added has higher priority than the default Environment " "(explained below). This means it can be overridden on a per-scene basis, " "which makes it quite useful." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 msgid "Default Environment" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:37 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44 msgid "" "A default environment can be set, which acts as a fallback when no " "Environment was set to a Camera or WorldEnvironment. Just head to Project " "Settings -> Rendering -> Environment:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:50 msgid "" "New projects created from the Project Manager come with a default " "environment (``default_env.tres``). If one needs to be created, save it to " "disk before referencing it here." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:45 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55 msgid "Environment Options" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:47 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 msgid "" "Following is a detailed description of all environment options and how they " "are intended to be used." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:64 msgid "" "The Background section contains settings on how to fill the background " "(parts of the screen where objects where not drawn). In Godot 3.0, the " "background not only serves the purpose of displaying an image or color, it " -"can change how objects are affected by ambient and reflected light." +"can also change how objects are affected by ambient and reflected light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71 msgid "There are many ways to set the background:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73 msgid "" "**Clear Color** uses the default clear color defined by the project. The " "background will be a constant color." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:60 -msgid "**Custom Color** is like Clear Color, but with a custom color value." +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:74 +msgid "**Custom Color** is like Clear Color but with a custom color value." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 msgid "" "**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a " "procedural sky (a simple sky featuring a gradient and an optional sun). " "Objects will reflect it and absorb ambient light from it." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76 msgid "" -"**Color+Sky** lets you define a sky (as above), but uses a constant color " +"**Color+Sky** lets you define a sky (as above) but uses a constant color " "value for drawing the background. The sky will only be used for reflection " "and ambient light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:66 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:80 msgid "Ambient Light" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82 msgid "" "Ambient (as defined here) is a type of light that affects every piece of " "geometry with the same intensity. It is global and independent of lights " "that might be added to the scene." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:86 msgid "" -"There are two types of ambient light, the *Ambient Color* (which is a " -"constant color multiplied by the material albedo), and then one obtained " -"from the *Sky* (as described before, but a sky needs to be set as background " -"for this to be enabled)." +"There are two types of ambient light: the *Ambient Color* (which is a " +"constant color multiplied by the material albedo) and then one obtained from " +"the *Sky* (as described before, but a sky needs to be set as background for " +"this to be enabled)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:94 msgid "" "When a *Sky* is set as background, it's possible to blend between ambient " "color and sky using the **Sky Contribution** setting (this value is 1.0 by " -"default for convenience, so only sky affects objects)." +"default for convenience so only sky affects objects)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:77 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98 msgid "Here is a comparison of how different ambient light affects a scene:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:81 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 msgid "" "Finally there is a **Energy** setting, which is a multiplier, useful when " "working with HDR." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:83 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 msgid "" "In general, ambient light should only be used for simple scenes, large " -"exteriors or for performance reasons (ambient light is cheap), as it does " +"exteriors, or for performance reasons (ambient light is cheap), as it does " "not provide the best lighting quality. It's better to generate ambient light " "from ReflectionProbe or GIProbe, which will more faithfully simulate how " "indirect light propagates. Below is a comparison in quality between using a " "flat ambient color and a GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:88 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 msgid "" "Using one of the methods described above, objects get constant ambient " "lighting replaced by ambient light from the probes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:91 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 msgid "Fog" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119 msgid "" "Fog, as in real life, makes distant objects fade away into an uniform color. " "The physical effect is actually pretty complex, but Godot provides a good " "approximation. There are two kinds of fog in Godot:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:95 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:123 msgid "" "**Depth Fog:** This one is applied based on the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:96 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124 msgid "" "**Height Fog:** This one is applied to any objects below (or above) a " "certain height, regardless of the distance from the camera." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128 msgid "" "Both of these fog types can have their curve tweaked, making their " "transition more or less sharp." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 msgid "Two properties can be tweaked to make the fog effect more interesting:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132 msgid "" "The first is **Sun Amount**, which makes use of the Sun Color property of " "the fog. When looking towards a directional light (usually a sun), the color " "of the fog will be changed, simulating the sunlight passing through the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:106 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:136 msgid "" "The second is **Transmit Enabled** which simulates more realistic light " "transmittance. In practice, it makes light stand out more across the fog." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:111 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142 msgid "Tonemap" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 msgid "" "Selects the tone-mapping curve that will be applied to the scene, from a " "short list of standard curves used in the film and game industry. Tone " @@ -21306,38 +21570,38 @@ msgid "" "result is not that strong. Tone mapping options are:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 msgid "" -"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic or Aces." +"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:116 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150 msgid "" -"**Exposure:** Tone mapping exposure, which simulates amount of light " -"received over time." +"**Exposure:** Tone mapping exposure which simulates amount of light received " +"over time." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:117 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 msgid "" -"**White:** Tone mapping white, which simulates where in the scale is white " +"**White:** Tone mapping white which simulates where in the scale is white " "located (by default 1.0)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154 msgid "Auto Exposure (HDR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:122 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 msgid "" "Even though, in most cases, lighting and texturing are heavily artist " "controlled, Godot suports a simple high dynamic range implementation with " -"auto exposure mechanism. This is generally used for the sake of realism, " -"when combining interior areas with low light and outdoors. Auto expure " -"simulates the camera (or eye) effort to adapt between light and dark " -"locations and their different amount of light." +"the auto exposure mechanism. This is generally used for the sake of realism " +"when combining interior areas with low light and outdoors. Auto exposure " +"simulates the camera (or eye) in an effort to adapt between light and dark " +"locations and their different amounts of light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:127 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 msgid "" "The simplest way to use auto exposure is to make sure outdoor lights (or " "other strong lights) have energy beyond 1.0. This is done by tweaking their " @@ -21347,149 +21611,149 @@ msgid "" "simulate indoor-oudoor conditions." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:130 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171 msgid "" "By combining Auto Exposure with *Glow* post processing (more on that below), " "pixels that go over the tonemap **White** will bleed to the glow buffer, " "creating the typical bloom effect in photography." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:134 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177 msgid "" "The user-controllable values in the Auto Exposure section come with sensible " "defaults, but you can still tweak then:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 msgid "" "**Scale:** Value to scale the lighting. Brighter values produce brighter " "images, smaller ones produce darker ones." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:139 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183 msgid "" "**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. " "Luminance is the average of the light in all the pixels of the screen." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 msgid "" "**Max Luma:** Maximum luminance that auto exposure will aim to adjust for." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:141 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185 msgid "" "**Speed:** Speed at which luminance corrects itself. The higher the value, " "the faster correction happens." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 msgid "Mid and Post-Processing Effects" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:146 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190 msgid "" "A large amount of widely-used mid and post-processing effects are supported " "in Environment." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 msgid "Screen-Space Reflections (SSR)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 msgid "" -"While Godot supports three sources of reflection data (Sky, ReflectionProbe " +"While Godot supports three sources of reflection data (Sky, ReflectionProbe, " "and GIProbe), they may not provide enough detail for all situations. " "Scenarios where Screen Space Reflections make the most sense are when " "objects are in contact with each other (object over floor, over a table, " "floating on water, etc)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 msgid "" "The other advantage (even if only enabled to a minimum), is that it works in " "real-time (while the other types of reflections are pre-computed). This is " "great to make characters, cars, etc. reflect when moving around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:159 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207 msgid "" "A few user-controlled parameters are available to better tweak the technique:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:161 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209 msgid "" "**Max Steps** determines the length of the reflection. The bigger this " "number, the more costly it is to compute." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:162 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:210 msgid "" "**Fade In** allows adjusting the fade-in curve, which is useful to make the " "contact area softer." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:163 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211 msgid "" "**Fade Out** allows adjusting the fade-out curve, so the step limit fades " "out softly." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:164 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 msgid "" "**Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. " "The bigger the value, the more gaps will be ignored." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213 msgid "" "**Roughness** will apply a screen-space blur to approximate roughness in " "objects with this material characteristic." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:167 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215 msgid "" "Keep in mind that screen-space-reflections only work for reflecting opaque " "geometry. Transparent objects can't be reflected." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:170 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:218 msgid "Screen-Space Ambient Occlusion (SSAO)" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:172 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220 msgid "" "As mentioned in the **Ambient** section, areas where light from light nodes " "does not reach (either because it's outside the radius or shadowed) are lit " "with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, " -"the Sky or a constant ambient color. The problem, however, is that all the " -"methods proposed before act more on larger scale (large regions) than at the " -"smaller geometry level." +"the Sky, or a constant ambient color. The problem, however, is that all the " +"methods proposed before act more on a larger scale (large regions) than at " +"the smaller geometry level." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:174 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 msgid "" -"Constant ambient color and Sky are uniform and the same everywhere, while GI " -"and Reflection probes have more local detail, but not enough to simulate " +"Constant ambient color and Sky are uniform and the same everywhere while GI " +"and Reflection probes have more local detail but not enough to simulate " "situations where light is not able to fill inside hollow or concave features." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:176 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231 msgid "" "This can be simulated with Screen Space Ambient Occlusion. As you can see in " "the image below, the goal of it is to make sure concave areas are darker, " "simulating a narrower path for the light to enter:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:180 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:237 msgid "" -"It is a common mistake to enable this effect, turn on a light and not be " +"It is a common mistake to enable this effect, turn on a light, and not be " "able to appreciate it. This is because SSAO only acts on *ambient* light, " "not direct light." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 msgid "" "This is why, in the image above, the effect is less noticeable under the " "direct light (at the left). If you want to force SSAO to work with direct " @@ -21497,143 +21761,144 @@ msgid "" "correct, some artists like how it looks)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 msgid "" "SSAO looks best when combined with a real source of indirect light, like " "GIProbe:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 msgid "Tweaking SSAO is possible with several parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:192 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252 msgid "" "**Radius/Intensity:** To control the radius or intensity of the occlusion, " "these two parameters are available. Radius is in world (Metric) units." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:193 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 msgid "" "**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining " "a large and a small radius AO generally works well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 msgid "" "**Bias:** This can be tweaked to solve self occlusion, though the default " "generally works well enough." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:195 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 msgid "" -"**Light Affect:** SSAO only affects ambient light, but increasing this " -"slider can make it also affect direct light. Some artists prefer this effect." +"**Light Affect:** SSAO only affects ambient light but increasing this slider " +"can make it also affect direct light. Some artists prefer this effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 msgid "" "**Quality:** Depending on quality, SSAO will do more samplings over a sphere " "for every pixel. High quality only works well on modern GPUs." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:197 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257 msgid "" "**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that " -"preserves local detail better, but is not as efficient (generally works " +"preserves local detail better but is not as efficient (generally works " "better with high quality setting above), while 3x3 will soften the image " -"better (with a bit of dithering-like effect), but does not preserve local " +"better (with a bit of dithering-like effect) but does not preserve local " "detail as well." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 msgid "" "**Edge Sharpness**: This can be used to preserve the sharpness of edges " "(avoids areas without AO on creases)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:201 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261 msgid "Depth of Field / Far Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:203 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "behind a given range. It has an initial **Distance** with a **Transition** " "region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:208 -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:219 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:269 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 msgid "" "The **Amount** parameter controls the amount of blur. For larger blurs, " -"tweaking the **Quality** may be needed in order to avoid arctifacts." +"tweaking the **Quality** may be needed in order to avoid artifacts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 msgid "Depth of Field / Near Blur" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276 msgid "" "This effect simulates focal distance on high end cameras. It blurs objects " "close to the camera (acts in the opposite direction as far blur). It has an " "initial **Distance** with a **Transition** region (in world units):" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:221 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:285 msgid "" "It is common to use both blurs together to focus the viewer's attention on a " "given object:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:292 msgid "Glow" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:229 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294 msgid "" -"In photography and film, when light amount exceeds the maxium supported by " +"In photography and film, when light amount exceeds the maximum supported by " "the media (be it analog or digital), it generally bleeds outwards to darker " "regions of the image. This is simulated in Godot with the **Glow** effect." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:234 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:300 msgid "" "By default, even if the effect is enabled, it will be weak or invisible. One " "of two conditions need to happen for it to actually show:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:236 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303 msgid "" "The light in a pixel surpasses the **HDR Threshold** (where 0 is all light " "surpasses it, and 1.0 is light over the tonemapper **White** value). " "Normally this value is expected to be at 1.0, but it can be lowered to allow " "more light to bleed. There is also an extra parameter, **HDR Scale** that " -"allows scaling (making brighter or darker) the light surpasing the threshold." +"allows scaling (making brighter or darker) the light surpassing the " +"threshold." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:240 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:307 msgid "" "The Bloom effect has a value set greater than 0. As it increases, it sends " "the whole screen to the glow processor at higher amounts." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:311 msgid "Both will cause the light to start bleeding out of the brighter areas." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:246 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313 msgid "Once glow is visible, it can be controlled with a few extra parameters:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315 msgid "" "**Intensity** is an overall scale for the effect, it can be made stronger or " "weaker (0.0 removes it)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:249 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316 msgid "" "**Strength** is how strong the gaussian filter kernel is processed. Greater " "values make the filter saturate and expand outwards. In general changing " @@ -21641,78 +21906,78 @@ msgid "" "**Levels**." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:251 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:318 msgid "The **Blend Mode** of the effect can also be changed:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:253 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320 msgid "" "**Additive** is the strongest one, as it just adds the glow effect over the " -"image with no blending involved. In general, it's too strong to be used, but " +"image with no blending involved. In general, it's too strong to be used but " "can look good with low intensity Bloom (produces a dream-like effect)." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:254 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:321 msgid "" "**Screen** is the default one. It ensures glow never brights more than " -"itself, and works great as an all around." +"itself and works great as an all around." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:255 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322 msgid "" "**Softlight** is the weakest one, producing only a subtle color disturbance " "around the objects. This mode works best on dark scenes." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:323 msgid "" "**Replace** can be used to blur the whole screen or debug the effect. It " "just shows the glow effect without the image below." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325 msgid "" "To change the glow effect size and shape, Godot provides **Levels**. Smaller " -"levels are strong glows that appear around objects, while large levels are " +"levels are strong glows that appear around objects while large levels are " "hazy glows covering the whole screen:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331 msgid "" "The real strength of this system, though, is to combine levels to create " "more interesting glow patterns:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:336 msgid "" "Finally, as the highest layers are created by stretching small blurred " -"images, it is possible that some blockyness may be visible. Enabling " +"images, it is possible that some blockiness may be visible. Enabling " "**Bicubic Upscaling** gets rids of it, at a minimal performance cost." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:272 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:343 msgid "Adjustments" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:274 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345 msgid "" "At the end of processing, Godot offers the possibility to do some standard " "image adjustments." msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:278 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:350 msgid "" -"The first one is being able to change the typical Brightness, Contrast and " +"The first one is being able to change the typical Brightness, Contrast, and " "Saturation:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355 msgid "" "The second is by supplying a color correction gradient. A regular black to " "white gradient like the following one will produce no effect:" msgstr "" -#: ../../docs/tutorials/3d/environment_and_post_processing.rst:286 +#: ../../docs/tutorials/3d/environment_and_post_processing.rst:360 msgid "" "But creating custom ones will allow to map each channel to a different color:" msgstr "" @@ -21753,10 +22018,10 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:30 msgid "" -"Except the scene is more contrasted, because there is a higher light range " -"in play. What is this all useful for? The idea is that the scene luminance " -"will change while you move through the world, allowing situations like this " -"to happen:" +"Except the scene is more contrasted because there is a higher light range at " +"play. What is this all useful for? The idea is that the scene luminance will " +"change while you move through the world, allowing situations like this to " +"happen:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:37 @@ -21808,11 +22073,11 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:71 msgid "" -"This is the most compatible way of using linear-space assets and it will " +"This is the most compatible way of using linear-space assets, and it will " "work everywhere including all mobile devices. The main issue with this is " "loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per " "channel to represent linear colors is inefficient from the point of view of " -"the human eye. These textures might be later compressed too, which makes the " +"the human eye. These textures might be later compressed too which makes the " "problem worse." msgstr "" @@ -21848,7 +22113,7 @@ msgstr "" msgid "" "Keep in mind that sRGB -> Linear and Linear -> sRGB conversions must always " "be **both** enabled. Failing to enable one of them will result in horrible " -"visuals suitable only for avant garde experimental indie games." +"visuals suitable only for avant-garde experimental indie games." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:102 @@ -21859,8 +22124,8 @@ msgstr "" msgid "" "HDR is found in the :ref:`Environment ` resource. These " "are found most of the time inside a :ref:`WorldEnvironment " -"` node, or set in a camera. There are many " -"parameters for HDR:" +"` node or set in a camera. There are many parameters " +"for HDR:" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:112 @@ -21875,23 +22140,24 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:117 msgid "" -"Linear: Simplest tonemapper. It does its job for adjusting scene brightness, " -"but if the differences in light are too big, it will cause colors to be too " -"saturated." +"**Linear:** Simplest tonemapper. It does its job for adjusting scene " +"brightness, but if the differences in light are too big, it will cause " +"colors to be too saturated." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:120 -msgid "Log: Similar to linear, but not as extreme." +msgid "**Log:** Similar to linear but not as extreme." msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:121 msgid "" -"Reinhardt: Classical tonemapper (modified so it will not desaturate as much)" +"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as " +"much)" msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:123 msgid "" -"ReinhardtAutoWhite: Same as above, but uses the max scene luminance to " +"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to " "adjust the white value." msgstr "" @@ -21902,7 +22168,7 @@ msgstr "" #: ../../docs/tutorials/3d/high_dynamic_range.rst:129 msgid "" "The same exposure parameter as in real cameras. Controls how much light " -"enters the camera. Higher values will result in a brighter scene and lower " +"enters the camera. Higher values will result in a brighter scene, and lower " "values will result in a darker scene." msgstr "" @@ -22116,9 +22382,9 @@ msgstr "" #: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9 msgid "" -"In a normal scenario you would use a :ref:`MeshInstance " +"In a normal scenario, you would use a :ref:`MeshInstance " "` node to display a 3D mesh like a human model for the " -"main character. But in some cases you would like to create multiple " +"main character, but in some cases, you would like to create multiple " "instances of the same mesh in a scene. You *could* duplicate the same node " "multiple times and adjust the transforms manually. This may be a tedious " "process and the result may look mechanical. Also, this method is not " @@ -22126,46 +22392,47 @@ msgid "" "` is one of the possible solutions to this problem." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:11 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 msgid "" "MultiMeshInstance, as the name suggests, creates multiple copies of a " "MeshInstance over a surface of a specific mesh. An example would be having a " -"tree mesh populate a landscape mesh with random scales and orientations." +"tree mesh populate a landscape mesh with trees of random scales and " +"orientations." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:14 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23 msgid "Setting up the nodes" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:16 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25 msgid "" -"The basic setup requires three nodes. Firstly, the MultiMeshInstance node. " -"Then, two MeshInstance nodes." +"The basic setup requires three nodes: the MultiMeshInstance node and two " +"MeshInstance nodes." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 msgid "" "One node is used as the target, the mesh that you want to place multiple " "meshes on. In the tree example, this would be the landscape." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:20 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31 msgid "" "Another node is used as the source, the mesh that you want to have " "duplicated. In the tree case, this would be the tree." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:22 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34 msgid "" "In our example, we would use a :ref:`Node ` as the root node of " "the scene. Your scene tree would look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:26 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39 msgid "For simplification purposes, this tutorial uses built-in primitives." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 msgid "" "Now you have everything ready. Select the MultiMeshInstance node and look at " "the toolbar, you should see an extra button called ``MultiMesh`` next to " @@ -22173,92 +22440,91 @@ msgid "" "window titled *Populate MultiMesh* will pop up." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:35 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51 msgid "MultiMesh Settings" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:37 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 msgid "Below are descriptions of the options." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:40 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 msgid "Target Surface" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 msgid "" "The mesh you would be using as the target surface for placing copies of you " "source mesh on." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:44 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 msgid "Source Mesh" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:45 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62 msgid "The mesh you want duplicated on the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:48 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 msgid "Mesh Up Axis" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:49 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66 msgid "The axis used as the up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:52 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 msgid "Random Rotation" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70 msgid "Randomizing the rotation around the mesh up axis of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 msgid "Random Tilt" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:57 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74 msgid "Randomizing the overall rotation of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:60 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 msgid "Random Scale" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78 msgid "Randomizing the scale of the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82 msgid "" "The scale of the source mesh that will be placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:68 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85 msgid "Amount" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86 msgid "The amount of mesh instances placed over the target surface." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:71 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88 msgid "" -"Select the target surface, in the tree case, this should be the landscape " -"node. And the source mesh should be the tree node. Adjust the other " -"parameters according to your preference. Press ``Populate`` and multiple " -"copies of the source mesh will be placed over the target mesh. If you are " -"satisfied with the result, you can delete the mesh instance used as the " -"source mesh." +"Select the target surface. In the tree case, this should be the landscape " +"node. The source mesh should be the tree node. Adjust the other parameters " +"according to your preference. Press ``Populate`` and multiple copies of the " +"source mesh will be placed over the target mesh. If you are satisfied with " +"the result, you can delete the mesh instance used as the source mesh." msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94 msgid "The end result should look like this:" msgstr "" -#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77 +#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98 msgid "To change the result, repeat the same step with different parameters." msgstr "" @@ -22280,28 +22546,27 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13 msgid "" "The Skeleton node can be directly added anywhere you want on a scene. " -"Usually mesh is a child of Skeleton, as it easier to manipulate this way, as " -"Transforms within a skeleton are relative to where the Skeleton is. But you " -"can specify a Skeleton node in every MeshInstance." +"Usually the target mesh is a child of Skeleton, as it easier to manipulate " +"this way, since Transforms within a skeleton are relative to where the " +"Skeleton is. But you can specify a Skeleton node in every MeshInstance." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18 msgid "" -"Being obvious, Skeleton is intended to deform meshes, and consists of " -"structures called \"bones\". Each \"bone\" is represented as a Transform, " -"which is applied to a group of vertices within a mesh. You can directly " -"control a group of vertices from Godot. For that please reference the :ref:" +"Naturally, Skeleton is intended to deform meshes and consists of structures " +"called \"bones\". Each \"bone\" is represented as a Transform, which is " +"applied to a group of vertices within a mesh. You can directly control a " +"group of vertices from Godot. For that please reference the :ref:" "`class_MeshDataTool` class and its method :ref:`set_vertex_bones " "`." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24 msgid "" -"The \"bones\" are organized hierarchically, every bone, except for root " -"bone(s) have a parent. Every bone has an associated name you can use to " -"refer to it (e.g. \"root\" or \"hand.L\", etc.). Also all bones are " -"numbered, these numbers are bone IDs. Bone parents are referred by their " -"numbered IDs." +"The \"bones\" are organized hierarchically. Every bone, except for root " +"bone(s) have a parent. Every bone also has an associated name you can use to " +"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and " +"these numbers are bone IDs. Bone parents are referred by their numbered IDs." msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30 @@ -22310,7 +22575,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38 msgid "" -"This scene is imported from Blender. It contains an arm mesh with 2 bones - " +"This scene is imported from Blender. It contains an arm mesh with 2 bones, " "upperarm and lowerarm, with the lowerarm bone parented to the upperarm." msgstr "" @@ -22321,7 +22586,7 @@ msgstr "" #: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44 msgid "" "You can view Godots internal help for descriptions of all functions. " -"Basically all operations on bones are done using their numeric ID. You can " +"Basically, all operations on bones are done using their numeric ID. You can " "convert from a name to a numeric ID and vice versa." msgstr "" @@ -22331,50 +22596,50 @@ msgid "" "function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:63 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61 msgid "**To find the ID of a bone, use the find_bone() function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:75 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73 msgid "" "Now, we want to do something interesting with the ID, not just printing it. " -"Also, we might need additional information - finding bone parents to " -"complete chains, etc. This is done with the get/set_bone\\_\\* functions." +"Also, we might need additional information, finding bone parents to complete " +"chains, etc. This is done with the get/set_bone\\_\\* functions." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:79 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77 msgid "" "**To find the parent of a bone we use the get_bone_parent(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:93 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91 msgid "" "The bone transforms are the things of our interest here. There are 3 kind of " -"transforms - local, global, custom." +"transforms: local, global, custom." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:96 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94 msgid "" "**To find the local Transform of a bone we use get_bone_pose(id) function:**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:112 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110 msgid "" "So we get a 3x4 matrix there, with the first column filled with 1s. What can " "we do with this matrix? It is a Transform, so we can do everything we can do " -"with Transforms, basically translate, rotate and scale. We could also " +"with Transforms (basically translate, rotate and scale). We could also " "multiply transforms to have more complex transforms. Remember, \"bones\" in " "Godot are just Transforms over a group of vertices. We could also copy " -"Transforms of other objects there. So lets rotate our \"upperarm\" bone:" +"Transforms of other objects there. So let's rotate our \"upperarm\" bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:140 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138 msgid "" -"Now we can rotate individual bones. The same happens for scale and translate " -"- try these on your own and check the results." +"Now we can rotate individual bones. The same happens for scale and " +"translate. Try these on your own and check the results." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:143 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141 msgid "" "What we used here was the local pose. By default all bones are not modified. " "But this Transform tells us nothing about the relationship between bones. " @@ -22382,137 +22647,146 @@ msgid "" "Here the global transform comes into play:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:148 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146 msgid "" "**To find the bone global Transform we use get_bone_global_pose(id) function:" "**" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:151 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149 msgid "Let's find the global Transform for the lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:167 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165 msgid "" "As you can see, this transform is not zeroed. While being called global, it " -"is actually relative to the Skeleton origin. For a root bone, origin is " -"always at 0 if not modified. Lets print the origin for our lowerarm bone:" +"is actually relative to the Skeleton origin. For a root bone, the origin is " +"always at 0 if not modified. Let's print the origin for our lowerarm bone:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:185 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183 msgid "" "You will see a number. What does this number mean? It is a rotation point of " "the Transform. So it is base part of the bone. In Blender you can go to Pose " -"mode and try there to rotate bones - they will rotate around their origin. " -"But what about the bone tip? We can't know things like the bone length, " -"which we need for many things, without knowing the tip location. For all " -"bones in a chain except for the last one we can calculate the tip location - " -"it is simply a child bone's origin. Yes, there are situations when this is " -"not true, for non-connected bones. But that is OK for us for now, as it is " -"not important regarding Transforms. But the leaf bone tip is nowhere to be " -"found. A leaf bone is a bone without children. So you don't have any " -"information about its tip. But this is not a showstopper. You can overcome " -"this by either adding an extra bone to the chain or just calculating the " -"length of the leaf bone in Blender and storing the value in your script." +"mode and try there to rotate bones. They will rotate around their origin." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:201 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188 +msgid "" +"But what about the bone tip? We can't know things like the bone length, " +"which we need for many things, without knowing the tip location. For all " +"bones in a chain, except for the last one, we can calculate the tip " +"location. It is simply a child bone's origin. There are situations when this " +"is not true, such as for non-connected bones, but that is OK for us for now, " +"as it is not important regarding Transforms." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195 +msgid "" +"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone " +"without children, so you don't have any information about its tip. But this " +"is not a showstopper. You can overcome this by either adding an extra bone " +"to the chain or just calculating the length of the leaf bone in Blender and " +"storing the value in your script." +msgstr "" + +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202 msgid "Using 3D \"bones\" for mesh control" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:203 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204 msgid "" "Now as you know the basics we can apply these to make full FK-control of our " -"arm (FK is forward-kinematics)" +"arm (FK is forward-kinematics)." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:206 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207 msgid "To fully control our arm we need the following parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:208 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 msgid "Upperarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210 msgid "Lowerarm angle x, y, z" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:211 -msgid "All of these parameters can be set, incremented and decremented." +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212 +msgid "All of these parameters can be set, incremented, and decremented." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:213 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214 msgid "Create the following node tree:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:222 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223 msgid "" "Set up the Camera so that the arm is properly visible. Rotate DirectionLight " "so that the arm is properly lit while in scene play mode." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:225 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226 msgid "Now we need to create a new script under main:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:227 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228 msgid "First we define the setup parameters:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:234 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235 msgid "Now we need to setup a way to change them. Let us use keys for that." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:236 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237 msgid "Please create 7 actions under project settings -> Input Map:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:238 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 msgid "**selext_x** - bind to X key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 msgid "**selext_y** - bind to Y key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 msgid "**selext_z** - bind to Z key" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 msgid "**select_upperarm** - bind to key 1" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 msgid "**select_lowerarm** - bind to key 2" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 msgid "**increment** - bind to key numpad +" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245 msgid "**decrement** - bind to key numpad -" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:246 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247 msgid "" "So now we want to adjust the above parameters. Therefore we create code " "which does that:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:272 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275 msgid "The full code for arm control is this:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:322 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327 msgid "" "Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, " "y, z, rotate using numpad \"+\"/\"-\"" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:325 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 msgid "" "This way you fully control your arm in FK mode using 2 bones. You can add " "additional bones and/or improve the \"feel\" of the interface by using " @@ -22520,31 +22794,31 @@ msgid "" "before going to next part." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335 msgid "You can clone the demo code for this chapter using" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:337 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 msgid "Or you can browse it using the web-interface:" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:339 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 msgid "https://github.com/slapin/godot-skel3d" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 msgid "Using 3D \"bones\" to implement Inverse Kinematics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 msgid "See :ref:`doc_inverse_kinematics`." msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352 msgid "Using 3D \"bones\" to implement ragdoll-like physics" msgstr "" -#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349 +#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354 msgid "TODO." msgstr "" @@ -22558,45 +22832,50 @@ msgstr "" #: ../../docs/tutorials/3d/inverse_kinematics.rst:8 msgid "" -"Before continuing on, I'd recommend reading some theory, the simplest " -"article I could find is this:" +"Previously, we were able to control the rotations of bones in order to " +"manipulate where our arm was (forward kinematics). But what if we wanted to " +"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to " +"rotate our bones in order to reach a desired position." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:11 -msgid "http://freespace.virgin.net/hugo.elias/models/m_ik2.htm" +#: ../../docs/tutorials/3d/inverse_kinematics.rst:13 +msgid "" +"A simple example of IK is the human arm: While we intuitively know the " +"target position of an object we want to reach for, our brains need to figure " +"out how much to move each joint in our arm to get to that target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:14 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:18 msgid "Initial problem" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:16 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:20 msgid "" "Talking in Godot terminology, the task we want to solve here is to position " -"our 2 angles we talked about above so, that the tip of the lowerarm bone is " -"as close to the target point (which is set by the target Vector3()) as " -"possible using only rotations. This task is calculation-intensive and never " -"resolved by analytical equation solving. So, it is an underconstrained " -"problem, which means there is an unlimited number of solutions to the " -"equation." +"the 2 angles on the joints of our upperarm and lowerarm so that the tip of " +"the lowerarm bone is as close to the target point (which is set by the " +"target Vector3) as possible using only rotations. This task is calculation-" +"intensive and never resolved by analytical equation solving, as it is an " +"under-constrained problem which means that there is more than one solution " +"to an IK problem." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:26 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:30 msgid "" -"For easy calculation, in this chapter we consider the target being a child " +"For easy calculation in this chapter, we consider the target being a child " "of Skeleton. If this is not the case for your setup you can always reparent " "it in your script, as you will save on calculations if you do so." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:31 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:35 msgid "" -"In the picture you see the angles alpha and beta. In this case we don't use " -"poles and constraints, so we need to add our own. On the picture the angles " -"are 2D angles living in a plane which is defined by bone base, bone tip and " -"target." +"In the picture, you see the angles alpha and beta. In this case, we don't " +"use poles and constraints, so we need to add our own. On the picture the " +"angles are 2D angles living in a plane which is defined by bone base, bone " +"tip, and target." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:36 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:40 msgid "" "The rotation axis is easily calculated using the cross-product of the bone " "vector and the target vector. The rotation in this case will be always in " @@ -22604,68 +22883,68 @@ msgid "" "get_bone_global_pose() function, the bone vector is" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:45 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:49 msgid "So we have all the information we need to execute our algorithm." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:47 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:51 msgid "" "In game dev it is common to resolve this problem by iteratively closing to " "the desired location, adding/subtracting small numbers to the angles until " "the distance change achieved is less than some small error value. Sounds " -"easy enough, but there are Godot problems we need to resolve there to " +"easy enough, but there are still Godot problems we need to resolve to " "achieve our goal." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:53 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:57 msgid "**How to find coordinates of the tip of the bone?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:54 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:58 msgid "**How to find the vector from the bone base to the target?**" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:56 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:60 msgid "" "For our goal (tip of the bone moved within area of target), we need to know " "where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we " "know the coordinate of the bone base is the tip of the parent bone. All " -"these calculations are quite dependent on the skeleton's structure. You can " -"use pre-calculated constants as well. You can add an extra bone at the tip " -"of the IK bone and calculate using that." +"these calculations are quite dependent on the skeleton's structure. You " +"could use pre-calculated constants, or you could add an extra bone at the " +"tip of the IK bone and calculate using that." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:66 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:70 msgid "We will use an exported variable for the bone length to make it easy." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:74 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:78 msgid "" "Now, we need to apply our transformations from the IK bone to the base of " -"the chain. So we apply a rotation to the IK bone then move from our IK bone " +"the chain, so we apply a rotation to the IK bone, then move from our IK bone " "up to its parent, apply rotation again, then move to the parent of the " "current bone again, etc. So we need to limit our chain somewhat." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:83 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:87 msgid "For the ``_ready()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:92 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:96 msgid "Now we can write our chain-passing function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:106 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:110 msgid "And for the ``_process()`` function:" msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:113 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:117 msgid "" "Executing this script will pass through the bone chain, printing bone " "transforms." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:143 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:147 msgid "" "Now we need to actually work with the target. The target should be placed " "somewhere accessible. Since \"arm\" is an imported scene, we better place " @@ -22673,14 +22952,14 @@ msgid "" "easily its Transform should be on the same level as the Skeleton." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:148 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 msgid "" -"To cope with this problem we create a \"target\" node under our scene root " -"node and at runtime we will reparent it copying the global transform, which " +"To cope with this problem, we create a \"target\" node under our scene root " +"node and at runtime we will reparent it, copying the global transform which " "will achieve the desired effect." msgstr "" -#: ../../docs/tutorials/3d/inverse_kinematics.rst:152 +#: ../../docs/tutorials/3d/inverse_kinematics.rst:156 msgid "" "Create a new Spatial node under the root node and rename it to \"target\". " "Then modify the ``_ready()`` function to look like this:" @@ -22693,8 +22972,8 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9 msgid "" "This tutorial will help you to use Godot shaders to deform a plane mesh so " -"it appears like a basic terrain. Remember that this solution has pros and " -"cons." +"that it appears like a basic terrain. Remember that this solution has pros " +"and cons." msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13 @@ -22738,7 +23017,7 @@ msgstr "" #: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31 msgid "" -"However, let's first create a heightmap,or a 2D representation of the " +"However, let's first create a heightmap, or a 2D representation of the " "terrain. To do this, I'll use GIMP, but you can use any image editor you " "like." msgstr "" @@ -30217,14 +30496,14 @@ msgid "Audio" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:4 -#: ../../docs/tutorials/audio/audio_buses.rst:43 +#: ../../docs/tutorials/audio/audio_buses.rst:45 msgid "Audio Buses" msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:9 msgid "" -"Beginning Godot 3.0, the audio engine has been rewritten from scratch. The " -"aim now is to present an interface much friendlier to sound design " +"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. " +"The aim now is to present an interface much friendlier to sound design " "professionals. To achieve this, the audio engine contains a virtual rack " "where unlimited audio buses can be created and, on each of it, unlimited " "amount of effect processors can be added (or more like, as long as your CPU " @@ -30244,40 +30523,44 @@ msgid "" "tradeoff between performance and sound quality." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:24 -msgid "Decibel Scale" +#: ../../docs/tutorials/audio/audio_buses.rst:23 +msgid "See also: the :ref:`doc_audio-buses` tutorial." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:26 +msgid "Decibel Scale" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:28 msgid "" "The new audio engine works primarily using the decibel scale. We have chosen " "this over linear representation of amplitude because it's more intuitive for " "audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:30 +#: ../../docs/tutorials/audio/audio_buses.rst:32 msgid "For those unfamiliar with it, it can be explained with a few facts:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:32 +#: ../../docs/tutorials/audio/audio_buses.rst:34 msgid "" "The decibel (dB) scale is a relative scale. It represents the ratio of sound " "power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:" "`10`\\ (P/P\\ :sub:`0`\\ ))." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:33 +#: ../../docs/tutorials/audio/audio_buses.rst:35 msgid "" "For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a " "factor 8, 10dB a factor 10, 20dB a factor 100, etc." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:34 +#: ../../docs/tutorials/audio/audio_buses.rst:36 msgid "" "Since the scale is logarithmic, true zero (no audio) can't be represented." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:35 +#: ../../docs/tutorials/audio/audio_buses.rst:37 msgid "" "0dB is considered the maximum audible volume without *clipping*. This limit " "is not the human limit but a limit from the sound hardware. Your sound " @@ -30285,37 +30568,37 @@ msgid "" "(clipping it)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:36 +#: ../../docs/tutorials/audio/audio_buses.rst:38 msgid "" "Because of the above, your sound mix should work in a way where the sound " "output of the *Master Bus* (more on that later), should never be above 0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:37 +#: ../../docs/tutorials/audio/audio_buses.rst:39 msgid "" "Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound " "volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so " "on." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:38 +#: ../../docs/tutorials/audio/audio_buses.rst:40 msgid "" "When working with decibels, sound is considered no longer audible between " "-60dB and -80dB. This makes your working range generally between -60dB and " "0dB." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:40 +#: ../../docs/tutorials/audio/audio_buses.rst:42 msgid "" "This can take a bit getting used to, but it's friendlier in the end and will " "allow you to communicate better with audio professionals." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:45 +#: ../../docs/tutorials/audio/audio_buses.rst:47 msgid "Audio buses can be found in the bottom panel of Godot Editor:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:49 +#: ../../docs/tutorials/audio/audio_buses.rst:51 msgid "" "An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where " "audio is channeled. Audio data passes through it and can be *modified* and " @@ -30323,7 +30606,7 @@ msgid "" "can measure the loudness of the sound in Decibel scale." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:51 +#: ../../docs/tutorials/audio/audio_buses.rst:53 msgid "" "The leftmost bus is the *Master Bus*. This bus outputs the mix to your " "speakers so, as mentioned in the item above (Decibel Scale), make sure that " @@ -30333,79 +30616,77 @@ msgid "" "to left without exception as this avoids creating infinite routing loops!" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:57 +#: ../../docs/tutorials/audio/audio_buses.rst:59 msgid "In the above image, *Bus 2* is routing its output to *Master* bus." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:60 +#: ../../docs/tutorials/audio/audio_buses.rst:62 msgid "Playback of Audio to a Bus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:62 +#: ../../docs/tutorials/audio/audio_buses.rst:64 msgid "" "To test playback to a bus, create an AudioStreamPlayer node, load an " "AudioStream and select a target bus for playback:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:66 +#: ../../docs/tutorials/audio/audio_buses.rst:68 msgid "Finally toggle the \"playing\" property to on and sound will flow." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:68 -msgid "" -"To learn more about *Audio Streams*, please read the related tutorial later! " -"(@TODO link to audio streams tute)" -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:71 -msgid "Adding Effects" +#: ../../docs/tutorials/audio/audio_buses.rst:70 +msgid "You may also be interested in reading about :ref:`doc_audio-buses` now." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:73 +msgid "Adding Effects" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:75 msgid "" "Audio buses can contain all sorts of effects. These effects modify the sound " "in one way or another and are applied in order." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:77 +#: ../../docs/tutorials/audio/audio_buses.rst:79 msgid "Following is a short description of available effects:" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:80 +#: ../../docs/tutorials/audio/audio_buses.rst:82 msgid "Amplify" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:82 +#: ../../docs/tutorials/audio/audio_buses.rst:84 msgid "" "It's the most basic effect. It changes the sound volume. Amplifying too much " "can make the sound clip, so be wary of that." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:85 +#: ../../docs/tutorials/audio/audio_buses.rst:87 msgid "BandLimit and BandPass" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:87 +#: ../../docs/tutorials/audio/audio_buses.rst:89 msgid "" "These are resonant filters which block frequencies around the *Cutoff* " "point. BandPass is resonant, while BandLimit stretches to the sides." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:90 +#: ../../docs/tutorials/audio/audio_buses.rst:92 msgid "Chorus" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:92 +#: ../../docs/tutorials/audio/audio_buses.rst:94 msgid "" "This effect adds extra voices, detuned by LFO and with a small delay, to add " "more richness to the sound harmonics and stereo width." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:95 +#: ../../docs/tutorials/audio/audio_buses.rst:97 msgid "Compressor" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:97 +#: ../../docs/tutorials/audio/audio_buses.rst:99 msgid "" "The aim of a dynamic range compressor is to reduce the level of the sound " "when the amplitude goes over a certain threshold in Decibels. One of the " @@ -30413,7 +30694,7 @@ msgid "" "the least possible (when sound goes over 0dB)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:100 +#: ../../docs/tutorials/audio/audio_buses.rst:102 msgid "" "Compressor has may uses in the mix, for example: * It can be used in the " "Master bus to compress the whole output (Although a Limiter is probably " @@ -30425,39 +30706,39 @@ msgid "" "attack, meaning it can make sound effects sound more punchy." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:107 +#: ../../docs/tutorials/audio/audio_buses.rst:109 msgid "" "There is a lot of bibliography written about compressors, and Godot " "implementation is rather standard." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:110 +#: ../../docs/tutorials/audio/audio_buses.rst:112 msgid "Delay" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:112 +#: ../../docs/tutorials/audio/audio_buses.rst:114 msgid "" "Adds an \"Echo\" effect with a feedback loop. It can be used, together with " "Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far " "apart." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:115 +#: ../../docs/tutorials/audio/audio_buses.rst:117 msgid "Distortion" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:117 +#: ../../docs/tutorials/audio/audio_buses.rst:119 msgid "" "Adds classical effects to modify the sound and make it dirty. Godot supports " "effects like overdrive, tan, or bit crushing. For games, it can simulate " "sound coming from some saturated device or speaker efficiently." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:121 +#: ../../docs/tutorials/audio/audio_buses.rst:123 msgid "EQ6, EQ10, EQ21" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:123 +#: ../../docs/tutorials/audio/audio_buses.rst:125 msgid "" "Godot provides three model of equalizers with different band counts. " "Equalizers are useful on the Master Bus to completely master a mix and give " @@ -30466,11 +30747,11 @@ msgid "" "headphones are plugged)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:127 +#: ../../docs/tutorials/audio/audio_buses.rst:129 msgid "HighPassFilter, HighShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:129 +#: ../../docs/tutorials/audio/audio_buses.rst:131 msgid "" "These are filters that cut frequencies below a specific *Cutoff*. A common " "use of high pass filters is to add it to effects (or voice) that were " @@ -30478,51 +30759,51 @@ msgid "" "commonly used for some types of environment like space." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:133 +#: ../../docs/tutorials/audio/audio_buses.rst:135 msgid "Limiter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:135 +#: ../../docs/tutorials/audio/audio_buses.rst:137 msgid "" "A limiter is similar to a compressor, but it's less flexible and designed to " "disallow sound going over a given dB threshold. Adding one in the *Master " "Bus* is always recommended to reduce the effects of clipping." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:139 +#: ../../docs/tutorials/audio/audio_buses.rst:141 msgid "LowPassFilter, LowShelfFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:141 +#: ../../docs/tutorials/audio/audio_buses.rst:143 msgid "" "These are the most common filters, they cut frequencies above a specific " "*Cutoff* and can also resonate. They can be used for a wide amount of " "effects, from underwater sound to simulating a sound coming from far away." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:145 +#: ../../docs/tutorials/audio/audio_buses.rst:147 msgid "NotchFilter" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:147 +#: ../../docs/tutorials/audio/audio_buses.rst:149 msgid "" "The opposite to the BandPassFilter, it removes a band of sound from the " "frequency spectrum at a given *Cutoff*." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:150 +#: ../../docs/tutorials/audio/audio_buses.rst:152 msgid "Panner" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:152 +#: ../../docs/tutorials/audio/audio_buses.rst:154 msgid "This is a simple helper to pan sound left or right." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:155 +#: ../../docs/tutorials/audio/audio_buses.rst:157 msgid "Phaser" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:157 +#: ../../docs/tutorials/audio/audio_buses.rst:159 msgid "" "It probably does not make much sense to explain that this effect is formed " "by two signals being dephased and cancelling each other out. It will be " @@ -30530,55 +30811,55 @@ msgid "" "like sounds." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:161 +#: ../../docs/tutorials/audio/audio_buses.rst:163 msgid "PitchShift" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:163 +#: ../../docs/tutorials/audio/audio_buses.rst:165 msgid "" "This effect allows for modulating pitch independently of tempo. All " "frequencies can be increased/decreased with minimal effect on transients. " "Can be used for effects such as voice modulation." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:166 +#: ../../docs/tutorials/audio/audio_buses.rst:168 msgid "Reverb" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:168 +#: ../../docs/tutorials/audio/audio_buses.rst:170 msgid "" "Reverb simulates rooms of different sizes. It has adjustable parameters that " "can be tweaked to obtain the sound of a specific room. Reverb is commonly " -"outputted from Areas (@TODO LINK TO TUTORIAL WHEN DONE), or to apply chamber " -"feel to all sounds." -msgstr "" - -#: ../../docs/tutorials/audio/audio_buses.rst:172 -msgid "StereoEnhance" +"outputted from Areas (see :ref:`doc_audio-buses` tutorial, look for the " +"section on Areas), or to apply chamber feel to all sounds." msgstr "" #: ../../docs/tutorials/audio/audio_buses.rst:174 +msgid "StereoEnhance" +msgstr "" + +#: ../../docs/tutorials/audio/audio_buses.rst:176 msgid "" "This effect has a few algorithms available to enhance the stereo spectrum, " "in case this is needed." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:177 +#: ../../docs/tutorials/audio/audio_buses.rst:179 msgid "Automatic Bus Disabling" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:179 +#: ../../docs/tutorials/audio/audio_buses.rst:181 msgid "" "There is no need to disable buses manually when not in use, Godot detects " "that the bus has been silent for a few seconds and disable it (including all " "effects)." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:184 +#: ../../docs/tutorials/audio/audio_buses.rst:186 msgid "Bus Rearrangement" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:186 +#: ../../docs/tutorials/audio/audio_buses.rst:188 msgid "" "Stream Players use bus names to identify a bus, which allows adding, " "removing and moving buses around while the reference to them is kept. If a " @@ -30587,11 +30868,11 @@ msgid "" "more common process than renaming them." msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:190 +#: ../../docs/tutorials/audio/audio_buses.rst:192 msgid "Default Bus Layout" msgstr "" -#: ../../docs/tutorials/audio/audio_buses.rst:192 +#: ../../docs/tutorials/audio/audio_buses.rst:194 msgid "" "The default bus layout is automatically saved to the \"res://" "default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from " @@ -30875,10 +31156,6 @@ msgid "" "collision response must be implemented in code." msgstr "" -#: ../../docs/tutorials/physics/physics_introduction.rst:55 -msgid "Collision Shapes" -msgstr "" - #: ../../docs/tutorials/physics/physics_introduction.rst:57 msgid "" "A physics body can hold any number of :ref:`Shape2D ` objects " @@ -32737,1532 +33014,6 @@ msgstr "" msgid "So the final algorithm is something like:" msgstr "" -#: ../../docs/tutorials/math/rotations.rst:4 -msgid "Rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:6 -msgid "" -"In the context of 3D transforms, rotations are the nontrivial and " -"complicated part. While it is possible to describe 3D rotations using " -"geometrical drawings and derive the rotation matrices, which is what most " -"people would be more familiar with, it offers a limited picture, and fails " -"to give any insight on related practical things such quaternions and SLERP. " -"For this reason, this document takes a different approach, a general " -"(although a little abstract at first) approach which was popularized by its " -"extensive use in local gauge theories in physics. That being said, the aim " -"of this text is to provide a minimal background to understand 2D and 3D " -"rotations in a general way and shed light on practical things such as gimbal " -"lock, quaternions and SLERP using an accessible language for programmers, " -"and not completeness or mathematical rigor." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:12 -msgid "A crash course in Lie groups and algebras for programmers" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:14 -msgid "" -"Lie groups is a branch of mathematics which deals with rotations in a " -"systematic way. While it is a extensive subject and most programmers haven't " -"even heard of it, it is relevant in game development, because it provides a " -"coherent and unified view of 3D rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:20 -msgid "" -"So let's start with small steps. Suppose that you want to make a tiny " -"rotation around some axis. For, concreteness let's say around :math:`z`-" -"axis by an infinitesimal angle :math:`\\delta\\theta`. For small angles, as " -"illustrated in the figure, the rotation operator can be written as :math:" -"`R_z(\\delta\\theta) = I + \\delta \\theta \\boldsymbol e_z \\times` " -"(neglecting higher order terms :math:`\\mathcal O(\\delta\\theta^2)` ) " -"where :math:`I` is identity operator and :math:`\\boldsymbol e_z` is a unit " -"vector along the :math:`z`-axis, such that a vector :math:`\\boldsymbol v` " -"becomes" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:26 -msgid "" -"(If this isn't clear, you can verify this by looking at the figure: :math:`" -"\\boldsymbol v` is rotated into :math:`\\boldsymbol v'` in the plane (so the " -"rotation axis :math:`\\boldsymbol e_z` is pointing out of screen). The " -"overlap of two vectors is :math:`\\boldsymbol v \\cdot \\boldsymbol v' = " -"v^2\\cos\\delta\\theta \\approx v^2 + \\mathcal O(\\delta\\theta^2)` since " -"the rotation is just a tiny amount, so the part of :math:`\\boldsymbol v'` " -"parallel to :math:`\\boldsymbol v` is indeed :math:`\\boldsymbol v`. Here, :" -"math:`v = |\\boldsymbol v|`. What about the perpendicular part, which must " -"be :math:`\\boldsymbol v' - \\boldsymbol v`? Using the right-hand rule, the " -"direction is :math:`\\boldsymbol e_z \\times \\boldsymbol v/v`, and to the " -"first order in :math:`\\delta\\theta`, we can approximate the length of the " -"difference vector by the arc length (blue arc in the figure) which is :math:`" -"\\delta \\theta v`, so the perpendicular component :math:`\\delta \\theta " -"\\boldsymbol e_z \\times \\boldsymbol v` also checks out.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:28 -msgid "" -"Now, a practical way of representing operators is by using matrices (note " -"that an `operator `_ " -"is not a matrix, and there are different mathematical objects other than " -"matrices which be used to represent operators, such as quaternions, a point " -"which we will come back to later when we're discussing `representations " -"`_ . In terms of real :" -"math:`3 \\times 3` matrices, the identity operator :math:`I` simply " -"corresponds to a :math:`3 \\times 3` identity matrix, and the cross product :" -"math:`\\boldsymbol e_z \\times` can be represented as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:38 -msgid "" -"(If you're curious how you can find the matrix representation of an " -"operator :math:`A` in some set of real basis :math:`\\{ \\boldsymbol e_i\\}" -"`: the matrix element on :math:`i` th row :math:`j` th column is given by :" -"math:`\\boldsymbol e_i \\cdot (A \\boldsymbol e_j)`; the basis we use here " -"is :math:`\\{ \\boldsymbol e_x, \\boldsymbol e_y, \\boldsymbol e_z \\}`) It " -"is no accident that :math:`J_z` rotates a vector in the :math:`xy` plane " -"around the :math:`z`-axis by :math:`\\pi/2`; for an arbitrary axis :math:`" -"\\boldsymbol n`, the operator :math:`J_n \\cong \\boldsymbol n \\times` is a " -"rotation by :math:`\\pi/2` around that axis for vectors in the plane " -"perpendicular to :math:`\\boldsymbol n`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:41 -msgid "" -"In terms of :math:`J_z`, we can express the infinitesimal rotation operator " -"around the :math:`z`-axis as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:47 -msgid "" -"So, how about finite rotations? We simply can apply this infinitesimal " -"rotation operator :math:`N` times to obtain a finite rotation :math:`\\theta " -"\\equiv N \\delta \\theta`:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:53 -msgid "" -"(If you're confused about seeing a matrix as an exponent: the meaning of an " -"operator :math:`A` in `exponential map `_ is given by its series expansion as :math:" -"`e^A = 1 + A + A^2/2! + \\ldots` ). This is arguably the most important " -"relation in this write up, and lies at the heart of Lie groups, whose " -"significance will be clarified in a moment. But first, let's take step back " -"and observe the significance of this result: using a simple picture of an " -"infinitesimal rotation, we derived a general expression for arbitrary " -"rotations around the :math:`z`-axis. In fact, this gets even better. If we " -"repeated the same analysis for rotations around :math:`x`- and :math:`y`-" -"axes, we would have obtained similar results :math:`e^{\\theta J_x}` and :" -"math:`e^{\\theta J_y}` respectively, where" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:68 -msgid "" -"Or, if we did a rotation around an arbitrary axis :math:`\\boldsymbol n`, " -"the result would have been" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:74 -msgid "" -"where :math:`\\boldsymbol J = (J_x, J_y, J_z)`. Note how the rotation axis :" -"math:`\\boldsymbol n` and rotation angle :math:`\\theta` plays a central " -"role in the final expression. Axis-angle is *the* parametrization for *all* " -"Lie groups, not just 3D rotations. (We will come back to this point later " -"when we're discussing Euler angle parametrization, which is an unnatural and " -"defective parametrization of rotations in 3D.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:77 -msgid "" -"If you ever tried to derive the rotation matrix corresponding to a :math:`" -"\\theta` rotation around :math:`\\boldsymbol n`, you can appreciate the " -"simplicity and elegance of how we obtained this result. To be fair, we still " -"need to figure out how to actually use an operator sitting on top of an " -"exponent (by summing up the Taylor series), of course, but that's merely a " -"\"programmatic\" labor and you just need to follow the finite multiplication " -"table of :math:`J_i` operators. But this is much straightforward than trying " -"to draw geometric diagrams and angles and figure out the rotation matrix. " -"For the particular case of the algebra corresponding to rotations in 3D " -"Euclidean space that we've been talking about so far, the exponent can " -"simply be written as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:83 -msgid "" -"which is known as Rodrigues' rotation formula. Note that we only ended up " -"with terms up to second order in :math:`\\boldsymbol n \\cdot \\boldsymbol " -"J` when we summed the series expansion; the reason is higher powers can be " -"reduced to 0th, 1st or 2nd order terms due to the relation :math:" -"`(\\boldsymbol n \\cdot \\boldsymbol J)^3 = -\\boldsymbol n \\cdot " -"\\boldsymbol J`, which makes summing up the series straightforward." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:85 -msgid "" -"The thing that sits on top of :math:`e`, which is a linear combination :math:" -"`J_i` operators (where :math:`i = x,y,z`), forms an algebra; in fact, it " -"forms a vector space whose basis \"vectors\" are :math:`J_i`. Furthermore, " -"the algebra is closed under the Lie bracket (which is essentially a " -"commutator: :math:`[a,b] = a b - ba`, and is something like a cross-product " -"in this vector space). In the particular case of 3D rotations, this " -"\"multiplication table\" is :math:`[J_x, J_y] = J_z` and its cyclic " -"permutations :math:`x\\to y, y\\to z, z\\to x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:87 -msgid "" -"Rotations form what is called a `group `_: simply put, it means that if you combine two " -"rotations, you get another rotation. And you can observe it here too: when " -"you put an element of the Lie algebra (which are simply linear combinations " -"of :math:`J_i` ) on top of :math:`e`, you get what is called a Lie group, " -"and the Lie algebra is said to *generate* the Lie group. For example, the " -"operator :math:`J_z \\equiv \\boldsymbol e_z \\times` is said to *generate* " -"the rotations around the :math:`z`-axis. The group of rotations in the 3D " -"Euclidean space is called SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:89 -msgid "" -"The order of rotations in 2D don't matter: you can first rotate by :math:`" -"\\pi` and rotate by :math:`\\pi/2`, or do it in reverse order, and either " -"way, the result is a rotation by :math:`3 \\pi/2` in the plane. But the " -"order of rotations in 3D do matter, in general, when different rotation axes " -"are involved (see `this picture `_ for " -"an example) (rotations around the same axes do commute, of course). When the " -"ordering of group elements don't matter, that group is said to be Abelian, " -"and non-Abelian otherwise. SO(2) is an Abelian group, and SO(3) is a non-" -"Abelian group." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:91 -msgid "" -"Lie groups and algebras are *not* matrices. You can *represent* both by " -"using object which emulate their \"multiplication\" rules: this can be real " -"or complex matrices of varying dimensions, or something like quaternions. A " -"single Lie group/algebra have infinitely many different representations in " -"vector spaces in different dimensions (see `these `_ for example for SO(3)). " -"Above, we use the 3D real representation of SO(3), which happens to be the " -"fundamental representation, and accidentally coincides with the adjoint " -"representation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:94 -msgid "Some mathematical remarks (feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:96 -msgid "" -"There are many different Lie groups, corresponding to different symmetries, " -"and they all have different names. For example, the group which contains all " -"rotations in :math:`n`-dimensional Euclidean space is called SO(:math:`n`), " -"and has :math:`n (n-1)/2` linearly independent generators (yes, Lie groups " -"can handle rotations is higher dimensions as-is, and even in non-Euclidean " -"ones). This is called the *rank* of the Lie algebra. You can think of the " -"generators as independent axes of rotations. For 2D, we can only rotate in " -"the :math:`xy` plane meaning we have only 1 generator. For 3D, you can " -"rotate around 3 different planes/axes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:98 -msgid "" -"Lie groups have deep connections with symmetries, and have played central " -"role in theoretical physics since around mid 20th century." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:100 -msgid "" -"For example, if something is symmetric under 3D rotation, that something (in " -"physics, it is typically Lagrangian, which leads to conservation laws " -"through Noether's theorem) remains invariant under SO(3) transformations (we " -"will cover transformations below)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:103 -msgid "" -"In the context of Lie groups and group theory in general, some common words " -"have specific meanings and a part of the math jargon: representation, " -"generator, group, algebra, parametrization, operator are such words. You " -"don't need to know their precise definitions to understand this write up; " -"just be aware that they are special terms and may not mean what you think " -"they mean. All of these terms a described in this write up in a colloquial " -"language." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:109 -msgid "Representation of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:111 -msgid "" -"Representation of rotations is an independent concept from parametrization " -"of rotations. These two concepts are commonly conflated, which leads to the " -"current state of confusion among many programmers. People tend to associate " -"Euler angles parametrization with matrices (or sometimes even vectors!), and " -"axis-angle parametrization with quaternions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:113 -msgid "" -"In game engines, rotation operators are represented using either matrices, " -"or quaternions. *As will be clear in what follows, you can use a matrix or a " -"quaternion to represent a rotation parameterized using Euler angles, and " -"same goes for axis-angle parametrization.* Unfortunately, even graphics " -"programming books and documentations of expensive game engines often make a " -"mistake here, and this causes programmers to start comparing Euler angles (a " -"parametrization) to quaternions (a representation) and even discussing their " -"trade-offs, which is \"not even wrong\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:115 -msgid "" -"`Representation `_ here " -"refers to a technical term in group theory. So will many other things that " -"will be mentioned in what follows. To gain a basic understand of these " -"concepts, let's first go through simpler and better understood example of " -"rotations in 2D first." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:119 -msgid "Representation of rotations in 2D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:121 -msgid "" -"Since there is only one possible axis of rotation in a two dimensional " -"plane, there is no Euler angle parametrization for them (or if you like, " -"there is only one Euler-angle). Rather, axis-angle parametrization is used, " -"with the axis being fixed to z-axis, which leaves only the angle of " -"rotation :math:`\\varphi` as a free parameter." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:123 -msgid "" -"A point in the 2D Euclidean space can be represented by a pair of 2D real " -"numbers as :math:`\\boldsymbol v = (x,y)` (called vector representation), or " -"they can alternatively be represented by a complex number as :math:`v = x + " -"\\imath y` where :math:`\\imath \\equiv \\sqrt{-1}` is the unit imaginary " -"number. In the vector representation, we can rotate the point through a " -"rotation matrix (an element of the Lie group SO(2), which can be represented " -"by :math:`2 \\times 2` orthogonal matrices with determinant +1) as follows:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:133 -msgid "" -"So for example, when :math:`\\theta=\\pi/2`, we get :math:`R(\\pi/2) " -"\\boldsymbol v = (-y,x)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:135 -msgid "" -"In the complex representation, a rotation is represented by a unit complex " -"number :math:`e^{\\imath\\theta} = \\cos\\theta + \\imath \\sin\\theta`, " -"where we used `Euler's formula `_, is an element of the Lie group U(1), which can be " -"represented by complex numbers of unit norm. Again, for :math:`\\theta=" -"\\pi/2`, you recover :math:`e^{\\imath\\pi/2}(x+\\imath y) = \\imath(x+" -"\\imath y) = (-y) + \\imath x`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:137 -msgid "" -"Rotations in the complex number representation look simpler, but it's only " -"an illusion: the complications of performing a matrix multiplication is " -"absorbed by the introduction of something that lives outside of the realm of " -"real numbers, which follows a rather \"odd\" algebra: :math:`\\imath^2 = " -"-1`. The way complex numbers mimic 2D rotations can be made clearer if we " -"rewrite the rotation matrix in terms of" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:151 -msgid "" -"as :math:`R(\\theta) = I_2 \\cos\\theta + J_z \\sin\\theta`, which can then " -"be compared to :math:`1 x + \\imath y` directly. Now we can see the " -"equivalence (the technical term is `isomorphism `_ in this context) of the representations clearer " -"through their multiplication table: :math:`I_2 I_2 = I_2, I_2 J_z = J_z, J_z " -"I_2 = J_z, J_z J_z = -I_2` which behaves the same way as :math:`1 \\times 1 " -"= 1, 1 \\times \\imath = \\imath, \\imath \\times 1 = \\imath, \\imath " -"\\times \\imath = -1`. Also note that both :math:`\\imath` and :math:`J_z` " -"represent a :math:`\\pi/2` rotation. And as it should be, :math:`\\imath` " -"and :math:`J_z` behave the same under multiplication." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:153 -msgid "" -"Furthermore, by Taylor series expansion, it is straightforward to show that :" -"math:`R(\\theta) = e^{J_z \\theta}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:155 -msgid "We have then the following table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -#: ../../docs/tutorials/math/rotations.rst:292 -msgid "What" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Matrix representation of SO(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:160 -msgid "Complex representation of U(1)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -#: ../../docs/tutorials/math/rotations.rst:294 -#: ../../docs/development/cpp/core_types.rst:143 -msgid "Vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`(x,y)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:162 -msgid ":math:`x+\\imath y`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "Generator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\begin{pmatrix} 0 & -1 \\\\ 1 & 0 \\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:164 -msgid ":math:`J_z \\cong \\imath`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "Rotation operator" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv I_2 \\cos\\theta + J_z\\sin\\theta \\equiv " -"\\begin{pmatrix}\\cos\\theta & -\\sin\\theta \\\\\\sin\\theta & \\cos\\theta " -"\\end{pmatrix}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:166 -msgid "" -":math:`e^{J_z \\theta} \\equiv e^{\\imath\\theta} = 1 \\cos\\theta + \\imath " -"\\sin\\theta`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:169 -msgid "" -"Clearly, introduction of the unit imaginary number is enough to capture the " -"behavior of 2D rotation matrices. As a footnote remark, while the number :" -"math:`e^{\\imath\\theta}` can only represent a rotation matrix, it can't of " -"course represent an arbitrary :math:`2 \\times 2` matrix (meaning no " -"scaling, no shearing, etc): after all, U(1) isn't isomorphic to :math:`" -"\\text{GL}(2, \\mathbb R)`, the group of all (invertible) real :math:" -"`2\\times 2` matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:171 -msgid "" -"The equivalence of these two seemingly different way of representing vectors " -"and rotations in 2D lies in the `isomorphism between the Lie groups SO(2) " -"and U(1) `_." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:174 -msgid "" -"Furthermore, in this representation, it is clear that you can do a \"smooth" -"\" rotation by slowly changing :math:`\\theta`, which is the 2D analogue of " -"SLERP (could as well be called Circular Linear Interpolation!). Note that if " -"you linearly interpolate the *elements* of two rotation matrices (that is, " -"linearly interpolating between :math:`R_{ij}` and :math:`R'_{ij}` ), you'll " -"get a weird trajectory with jerky motion; to do SLERP with a matrix, you " -"need to extract the angles from each matrix (which can only happen for " -"matrices whose entries have to form given by :math:`R(\\theta)` above; that " -"is, elements of SO(2)), interpolate between the angles linearly, and " -"construct the intermediate matrix using that angle." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:176 -msgid "" -"The take-aways of this short visit to the more understandable 2D land are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:178 -msgid "" -"There can be different (but \"equivalent\", of course) *representations* of " -"rotations: like matrices and complex numbers." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:179 -msgid "" -"Despite the fact that you can use complex numbers to represent vectors and " -"rotations in 2D, the *concept* of rotations in 2D doesn't require an " -"understanding/knowledge of complex numbers or Euler's formula." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:180 -msgid "" -"The introduction of the imaginary :math:`\\imath` is not black magic: it's " -"just something that mimics :math:`2 \\times 2` matrix :math:`J_z`: :math:`1` " -"and :math:`\\imath` behave the same way as :math:`I_2` and :math:`J_z` under " -"multiplication (see the group multiplication table given above)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:182 -msgid "" -"These are often sources of confusion in 3D: introducing a third dimension " -"means we have new rotation axes (rotations around X and Y axes) giving rise " -"to alternative parametrizations (such as Euler angles), and new generators :" -"math:`J_x` and :math:`J_y`, which will be the generalization of :math:`J_z` " -"above." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:186 -msgid "Some mathematical remarks (again, feel free to skip)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:187 -msgid "" -"The fact that SO(3) has 3 generators is an accident: SO(:math:`n`) has :math:" -"`n(n-1)/2` generators. Furthermore, the next step (after quaternions, which " -"is `another accident `_) of `Cayley-Dickson construction " -"`_ does " -"*not* correspond to a Lie algebra, but rather a non-associative algebra " -"called `octonions `_. Rather, in " -"arbitrary dimensions, the \"complex\" representation can be written using " -"the generators of Spin(:math:`n`), which is a double cover of SO(:math:`n`). " -"Also, throughout this page, when we say representation of SO(2), U(1) or any " -"other group, we are talking about the `*fundamental* `_ `irreducible representation `_, corresponding to a " -"`Young diagram `_ with a single " -"box." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:191 -msgid "Representation of rotations in 3D" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:193 -msgid "" -"Let's first review how 3D rotations work using familiar vectors and matrices." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:195 -msgid "" -"In 2D, we considered vectors lying in the :math:`xy` plane, and the only " -"axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform " -"a rotation around any axis. And this doesn't just mean around :math:`x, y, " -"z` axes, the rotation can also be around an axis which is a linear " -"combination of those, where :math:`\\boldsymbol n` is the unit vector " -"(meaning :math:`\\boldsymbol n \\cdot \\boldsymbol n = 1` ) aligned with the " -"axis we want to perform the rotation." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:198 -msgid "" -"Just like the 2D rotation matrix, the 3D rotation matrix can also be derived " -"with some effort by drawing lots of arrows and angles and some linear " -"algebra, but this would be opaque and won't give us much insight to what's " -"going on. A less straightforward, but more rewarding way of deriving this " -"matrix is to understand the rotation group SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:200 -msgid "" -"SO(3) is the group of rotations in Euclidean 3D space (for which the " -"`signature `_ is :math:`(+1," -"+1,+1)`), which preserve the magnitude and handedness of the vectors it acts " -"on. The most typical way to represent its elements is to use :math:`3 " -"\\times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`" -"\\text{Mat}(3, \\mathbb R)` representation is called the fundamental " -"representation of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:202 -msgid "" -"To recap what we discussed earlier, SO(3) has 3 generators, :math:`J_x, J_y, " -"J_z` and we found that they can be represented using these :math:`3\\times " -"3` real matrices:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:223 -msgid "" -"These matrices have the same \"multiplication table\" as :math:`J_i` " -"(they're isomorphic), so for all practical purposes, you can replace the " -"operators with their matrix representations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:225 -msgid "We also found that an element of SO(3), that is, a rotation operator is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:231 -msgid "" -"If you want, you can plug-in the matrix representations for :math:`J_i` and " -"derive the complicated :math:`3\\times 3` rotation matrix which is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:242 -msgid "" -"(Hint: you can use the relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"J)^2 = \\boldsymbol n \\otimes \\boldsymbol n-I` to quickly evaluate the " -"last term in the Rodrigues' formula, where :math:`\\otimes` is the " -"`Kronecker product `_ which " -"is also called `outer product `_ for vectors. Using the `half-angle formulae `_ " -"to rewrite :math:`\\sin\\varphi = 2 \\cos\\frac{\\varphi}{2} \\sin" -"\\frac{\\varphi}{2}` and :math:`1-\\cos\\varphi = 2 \\sin^2\\frac{\\varphi}" -"{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual " -"aid when comparing to the matrix form.)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:244 -msgid "" -"However, we don't *have to* use matrices to represent SO(3) generators :math:" -"`J_i`. Remember how we used :math:`\\imath`, the imaginary unit to emulate :" -"math:`J_z` rather than using a :math:`2 \\times 2` matrix? As it turns out " -"we can do something similar here." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:246 -msgid "" -"`Hamilton `_ is mostly " -"commonly known for the omnipresent `Hamiltonian `_ in physics. One of his less known " -"contributions is essentially an alternative way of representing 3D cross " -"product, which eventually gave in to popularity of usual vector `cross " -"products `_. He " -"essentially realized that there are three different non-commuting rotations " -"in 3D, and gave a name to the generator for each. He identified the " -"operators :math:`\\{\\boldsymbol e_x \\times, \\boldsymbol e_y \\times, " -"\\boldsymbol e_z \\times\\}` as the elements of an algebra, naming them as :" -"math:`\\{i,j,k\\}`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:248 -msgid "" -"This may sound trivial at this point, because we're equipped with all the " -"machinery of Lie groups and Lie algebras: apparently, quaternion units :math:" -"`\\{i,j,k\\}` are just another representation of the SO(3) generators, which " -"satisfy the Lie bracket. Well, no so fast. While the Lie *algebra* :math:`" -"\\mathfrak{so}(3)`, whose elements are the linear combination of :math:`J_i` " -"s are isomorphic to unit quaternions, but quaternions are :math:`1 w + x i + " -"y j + z k` in general, so there's also an identity part, which isn't a " -"vector that is a part of any Lie algebra. Quaternions look more like the " -"*group* SO(3) (when they're normalized, because SO(3) preserves vector " -"norms). But it actually isn't isomorphic to SO(3). It turns out that unit " -"quaternions are isomorphic to the group SU(2) (which is isomorphic to " -"Spin(3)), which in turn is a double cover of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:251 -msgid "" -"SU(2) is essentially the group of unitary rotations with determinant +1 " -"(called Special Unitary groups) which preserve the norm of complex vectors " -"it acts on, generated by `Pauli spin matrices `_ :math:`\\sigma_i`, and :math:`i,j,k` correspond to :math:`" -"\\sigma_x/\\imath\\ \\sigma_y/\\imath, \\sigma_z/\\imath`. To exemplify, :" -"math:`R = e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J} \\in \\text{SO}" -"(3)` rotates a real vector by :math:`R \\boldsymbol v` and the corresponding " -"rotation :math:`U = e^{-\\imath\\varphi \\boldsymbol n \\cdot \\boldsymbol " -"\\sigma/2} \\in \\text{SU}(2)` rotates the same vector through :math:`U " -"(\\boldsymbol v \\cdot \\boldsymbol \\sigma) U^\\dagger`. Note that :math:`U " -"\\to -U` achieves the same SO(3) rotation, SU(2) it's said to be a double " -"cover of SO(3) (this is mapping gives the adjoint representation of SU(2) by " -"the way). Here :math:`-\\imath\\boldsymbol \\sigma = -\\imath (\\sigma_x, " -"\\sigma_y, \\sigma_z) \\cong (i,j,k)`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:253 -msgid "" -"SU(2) and SO(3) look the same locally (their tangent spaces dictated by " -"their Lie algebras are isomorphic), but they're different globally. While " -"this sounds like just a technicality, this has topological implications, but " -"we won't get into that much. The take away from this discussion is that unit " -"quaternions *can* be used emulate SO(3) rotations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:255 -msgid "" -"But taking a step back, why do we bother *emulating* SO(3) at all? For " -"computational purposes, we already have something that works: the matrix " -"representation. Why do we need to both with a weird group that isn't even " -"exactly the same as SO(3)?" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:258 -msgid "" -"The answer is the cost of computation, and this is two fold. First, you see, " -"a rotation operator has only 3 degrees of freedom: two for the unit vector " -"which is the rotation axis, and one for the rotation angle around that axis. " -"A :math:`3\\times 3` matrix, on the other hand has 9 elements. It's an " -"overkill. For example, whenever you multiply two rotations, you need to " -"multiply two :math:`3\\times 3` matrices, summing and multiplying every " -"single element. In terms of CPU cycles, this is wasted effort and we can be " -"more optimal. Second part is precision errors. The errors are worse in " -"matrix representation, because originally, we have only 3 degrees of " -"freedom, which means we can have precision errors in axis and angle (only 3 " -"errors) but it's still an element of SO(3), whereas with matrices, we can " -"have errors in any one of the 9 elements in the matrix and so we can even " -"have a matrix that isn't even an element of SO(3). These errors can quickly " -"build up quickly especially if you're for example modifying the orientation " -"of an object every frame by doing a smooth interpolation between an initial " -"and a target orientation (discussed further in SLERP section)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:260 -msgid "" -"Sure, we know that elements of SO(3) can be represented by using orthogonal " -"matrices with determinant +1 (hence the name Special Orthogonal) such that :" -"math:`R R^T = I`; in plain language, this means the columns of :math:`R` " -"form an orthonormal set of vectors, so we can eliminate the errors if we " -"perform `Gram-Schmidt `_ orthonormalization once in a while, and force it " -"back into SO(3), such that it's an actual rotation matrix (albeit still " -"noisy in axis and angle). But this is expensive and still quite bad in terms " -"of errors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:262 -msgid "" -"So, what is the alternative then? Shall we go back to the Rodrigues' formula " -"and hardcode the behavior of :math:`J_i` into our program? A nicer " -"alternative is, we use SU(2) (which we know covers SO(3), twice in fact!), " -"because the equivalent of the Rodrigues' formula is much simpler:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:268 -msgid "" -"owing to the nice relation :math:`(\\boldsymbol n \\cdot \\boldsymbol " -"\\sigma)^2 = I` (something like this happens only at the third power with " -"SO(3) generators, remember? and it doesn't give identity), or if you prefer " -"quaternion version which is more commonly used to represent the isomorphic " -"group Spin(3), this is" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:274 -msgid "" -"In game engines, rather than storing the axis-angle :math:`(\\boldsymbol " -"n(\\phi,\\theta), \\varphi )` pair where :math:`\\phi,\\theta` are the " -"azimuthal and polar angles parametrizing the unit vector :math:`\\boldsymbol " -"n`, people typically store :math:`\\boldsymbol q= (q_0, q_x, q_y, q_z) " -"\\equiv (\\cos\\frac{\\varphi}{2}, \\sin\\frac{\\varphi}{2} n_x, \\sin" -"\\frac{\\varphi}{2} n_y, \\sin\\frac{\\varphi}{2} n_z)` such that :math:`U = " -"\\boldsymbol q \\cdot (1, i, j, k)`, and enforce the condition :math:`|" -"\\boldsymbol q|=1` once in a while by renormalization (note that while you " -"can see many people referring to :math:`\\boldsymbol q` as a quaternion, " -"it's not; :math:`U` is the actual quaternion here and :math:`\\boldsymbol q` " -"is just an artificial vector containing the coefficients in the expansion of " -"the exponential map). Of course, if they store :math:`(\\varphi, \\phi, " -"\\theta)`, there is no need for a renormalization because such " -"parametrization guarantees the normalization, but this choice would come at " -"the cost of calculating a bunch of sines and cosines whenever you use them, " -"so this is a middle ground in terms of errors and speed." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:276 -msgid "So, the take aways of this section are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:278 -msgid "" -"Matrices can represent SO(3) just fine, but are a little too general and " -"extravagant in terms of CPU cycles and behave bad in the presence of " -"floating point errors, and errors can even lead to a matrix that doesn't " -"correspond to a rotation matrix at all!" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:280 -msgid "" -"For all practical purposes, we can use an element of SU(2) to represent an " -"SO(3) rotation. It's a double cover of SO(3), so we wouldn't be losing " -"anything in doing so. The main reason for choosing one over another is the " -"SO(3) Rodrigues' formula is a little nasty to work with whereas SU(2) " -"expansion is neat, clean and simple to work with." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:282 -msgid "" -"Using matrices, you can practically do everything you do with quaternions, " -"vice versa. The real differences, as highlighted, are in computation trade-" -"offs, not mathematics." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:284 -msgid "" -"The relationship between quaternions and 3D rotation matrices is the roughly " -"the same as the relation between the complex number :math:`e^{\\imath\\theta}" -"` and a 2D rotation matrix. Just as the complex number :math:`\\imath \\cong " -"J_z` rotates by :math:`\\pi/2` (which is, as we saw, what a *generator* " -"does), :math:`i,j,k` (which are :math:`\\cong J_x, J_y, J_z`) rotate by :" -"math:`\\pi/2` around :math:`x, y, z` axes; they don't commute with each " -"other because in 3D, the order of rotations is important. Owing to this " -"isomorphism between their generators, an SO(3) rotation :math:`e^{\\varphi " -"\\boldsymbol n \\cdot \\boldsymbol J}` corresponds to the SU(2) rotation :" -"math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}`. This is a helpful " -"picture to gain an intuition on quaternions. While the SO(3) is familiar to " -"many people, the \"Rodrigues' formula\" for the SU(2) one is much " -"preferable graphics programming due to it's simplicity, and hence you see " -"quaternions in game engines." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:286 -msgid "" -"This doesn't mean quaternions are a generalization of complex numbers in our " -"construction when considering rotations in a strict sense; they're rather " -"the 3D generalization of the 2D rotation generator in some loose sense " -"(loose, because SO(3) and SU(2) are different groups). There *is* a " -"construction which generalizes real numbers to complex numbers to " -"quaternions, called `Cayley-Dickson construction `_, but it's next steps give off " -"topic objects octonions and sedenions (setting exceptional Lie groups aside " -"for octonions)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:288 -msgid "" -"Note that we haven't said a word about Euler angles. In both matrix and " -"quaternion *representations*, we sticked to the axis-angle " -"*parametrization*. We will discuss different parametrizations in what " -"follows." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Matrix representation of SO(3)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:292 -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Quaternion representation of SU(2)" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid ":math:`(x,y,z)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:294 -msgid "" -":math:`\\sqrt{r}(\\cos\\frac{\\theta}{2}, e^{\\imath \\phi} \\sin" -"\\frac{\\theta}{2})`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid "" -"Matrices for :math:`J_x, J_y, J_z \\cong \\boldsymbol e_x \\times, " -"\\boldsymbol e_y \\times, \\boldsymbol e_z \\times`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:296 -msgid ":math:`i,j,k`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J}`, can expand with " -"Rodrigues' formula" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:298 -msgid "" -":math:`e^{\\varphi \\boldsymbol n \\cdot (i,j,k)/2}` can expand with SU(2) " -"\"Rodrigues' formula\"" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:301 -msgid "" -"Above, :math:`r,\\theta,\\phi` are spherical coordinates corresponding to :" -"math:`x,y,z`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:304 -msgid "A note about the SU(2) vector" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:306 -msgid "" -"We earlier mentioned that rotation of a real vector in SU(2) is done via :" -"math:`(R \\boldsymbol v) \\cdot \\boldsymbol \\sigma = U (\\boldsymbol v " -"\\cdot \\boldsymbol \\sigma) U^\\dagger`, and you may be wondering what the " -"complex vector listed above :math:`|\\psi\\rangle = (\\cos\\frac{\\theta}" -"{2}, e^{\\imath \\phi} \\sin\\frac{\\theta}{2})` has to do with that. The " -"answer is, there vector :math:`|\\psi\\rangle` is the one a single :math:`U` " -"acts on, and in terms of it, we can rewrite :math:`U (\\boldsymbol v \\cdot " -"\\boldsymbol \\sigma) U^\\dagger` as :math:`r U (|\\psi\\rangle \\otimes " -"\\langle \\psi|) U^\\dagger` up to some trivial identity term, where :math:`" -"\\langle \\psi| = |\\psi\\rangle^\\dagger` (this is the way complex vectors " -"are typically denoted in quantum mechanics and is called `bra-ket notation " -"`_: bra is like the " -"vector and ket is the `conjugate transpose `_, and people typically omit the :math:`\\otimes` in " -"between because that's already implied when you multiply a ket with a bra, " -"and likewise there is no :math:`\\cdot` when you multiply a bra with ket " -"since that's also implied)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:308 -msgid "" -"So, notational concerns aside, long story short, the vector listed above is " -"in a generalized sense \"half\" of what we are rotating:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:314 -msgid "" -"and each \"half\" goes to one of the :math:`U` s on each side of the " -"modified/generalized relation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:320 -msgid "" -"so everything is compatible, and :math:`|\\psi'\\rangle = U |" -"\\psi(\\boldsymbol v)\\rangle = |\\psi(R \\boldsymbol v)\\rangle` is " -"satisfied. This parametrization of an SU(2) vector is typically done in " -"spherical coordinates :math:`\\theta,\\phi` (for :math:`r=1`, because state " -"vectors are normalized in quantum mechanics), and the sphere is called " -"`Bloch sphere `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:323 -msgid "Parametrization of rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:325 -msgid "" -"From general arguments of linear independence, it is clear that a general " -"rotation in 3D requires 3 independent parameters, which is known as `Euler's " -"rotation theorem `_. " -"It is tempting to think rotations as three-dimensional vectors, but they are " -"rather `linear operators `_ that " -"transform vectors." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:328 -msgid "" -"There are `different ways of parametrizing rotations `_ in the `3D Euclidean space " -"`_ using 3 parameters, and we " -"will go through the two commonly used in game programming." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:332 -msgid "Axis-angle parametrization: :math:`(\\phi, \\theta, \\varphi)`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:334 -msgid "" -"As we found out, this is the *de facto* parametrization of rotations in 3D " -"(or in fact, in any dimensions), which is also the direct generalization of " -"rotations in 2D, is this: choose an axis in 3D space (a unit vector to " -"specify a direction, which has two independent parameters, because its " -"length is conventionally fixed to 1) and is typically parametrized using " -"`polar and azimuthal angles `_ as :math:`\\boldsymbol n(\\phi,\\theta) = " -"(\\sin\\theta \\cos\\phi, \\sin\\theta \\sin\\phi,\\cos\\theta)` and specify " -"the angle of rotation around that axis :math:`\\varphi` (which is the third " -"parameter) whose sense of rotation is fixed by the `right-hand rule `_ (for a right-hand coordinate " -"system). For (embedded) 2D rotations in the :math:`xy`-plane, the rotation " -"axis is taken to be the z-axis, and we only need to specify the rotation " -"angle. In 3D, the rotation axis can be pointing toward any direction (since " -"the axis is a unit vector, you can think of it as a point on the unit " -"sphere, if you like). This way of parametrizing rotations is called axis-" -"angle parametrization, and is the easiest to picture intuitively." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:340 -msgid "" -"Another advantage of the axis angle parametrization is, it is easy to " -"interpolate between two different rotations (let's call their parameters :" -"math:`\\boldsymbol n_1, \\varphi_1` and :math:`\\boldsymbol n_2, " -"\\varphi_2`), which is useful when you're changing the orientation of an " -"object, starting from a given initial orientation and going toward a final " -"one. A nice way of doing this is described in a later section where we " -"describe SLERP. It results in a smooth motion, rather than a \"jerky\" " -"motion which may start fast, go slow in the middle and go fast again etc. It " -"turns out that if a mass is transported this way, it experiences the least " -"amount of torque (compared to other possible trajectories). This way of " -"linearly interpolating rotations in the axis-angle parametrization is called " -"Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in " -"games." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:345 -msgid "" -"Euler angles (and Tait-Bryan angles): :math:`(\\varphi_1, \\varphi_2, " -"\\varphi_3 )`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:347 -msgid "" -"Another way of parametrizing 3D rotations is by considering a sequence of at " -"least 3 rotations around certain, fixed axes. This could be, for example " -"\"rotate around the :math:`Z`-axis by :math:`\\varphi_1`, then rotate around " -"the :math:`Y`-axis by :math:`\\varphi_2`, and finally rotate around the :" -"math:`x`-axis by :math:`\\varphi_3`\". Of course, these axes don't have to " -"be Z, then Y, then X. As long as two sequential rotations are not around the " -"same axis (in which case they would combine into a single rotation, hence " -"reducing the number of actually independent parameters by 1), they can be " -"anything. They don't even need to be aligned with any \"named\" axis. " -"Another thing important think to watch out is, if you imagine that there is " -"a local coordinate system \"painted\" on the object, as you go through the 3-" -"step rotation sequence, that local frame rotates with the object itself, " -"while the global frame of course remains as-is. The rotation angles " -"specified with respect to a global, fixed reference frame are sometimes " -"called Tait-Bryan angles. So when we're specifying a general rotation in " -"terms of 3 rotations around certain \"fixed\" axes, you need to specify " -"whether those axes refer to the global (called extrinsic, usually written " -"with an additional prime, :math:`X'` rather than :math:`X`, after each " -"rotation ) or the local (called intrinsic) frame as well. Typically, " -"extrinsic is used as it is relatively easier to picture, and axes are chosen " -"to coincide with X,Y or Z. The 3 rotation angles used in such representation " -"of rotations is called Euler angles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:354 -msgid "" -"Ancient mechanical devices called gimbal (which are long obsolete in this " -"age) used to calculate realize 3D rotations in engineering applications in " -"vehicles increased the popularity of Euler angles. Furthermore, since the :" -"math:`3 \\times 3` rotation matrix around X,Y or Z axis is easier to write " -"down, it is commonly said that Euler angles are easier to understand when " -"compared to axis-angle representation (which is commonly, although not " -"necessarily, implemented through quaternions). While this may be true if " -"you're creating a linear algebra library from scratch, or filling in the " -"elements of the transformation matrix on your own, this is not the case when " -"writing games with game engines, such as Godot. The popularity of Euler " -"angles endured despite the fact that they, in fact, can not represent a " -"smooth transition between two different rotations by a smooth variation of " -"the three angles. The reason behind this lies in the fact that Euler angles " -"describe a chart on 3-torus, which is not a `covering map `_ of SO(3), three dimensional rotations " -"(if this sounds too abstract, see the subsection about 3-torus and sphere " -"below). As the mapping from Euler angles to SO(3) is ill-defined at certain " -"points, during the smooth interpolation between two rotations, we may bump " -"into such points, and as a result the rank may drop to 2 or even 1 (which " -"mechanically corresponds to a situation in which two or three gimbals become " -"aligned as they go around), which is known as the `gimbal-lock `_ problem. Thus, while it's OK to use Euler " -"angles to represent a fixed rotation, they're not suitable for slowly " -"changing the orientation of objects. You can still do that if you put some " -"additional effort to avoid gimbal-lock, of course, but even if by some luck " -"you don't bump into such bad points, a linear interpolation between two sets " -"of Euler angles is going to result in a \"jerky\" motion." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:361 -msgid "" -"All in all, despite being an ill-defined parametrization for rotations, " -"Euler angles enjoyed a popularity due to gimbals." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:363 -msgid "" -"While Euler angles may not be too useful when calculating the rotation " -"operator (be it a matrix or a quaternion) in body dynamics, people still " -"find them useful to think about and describe the *orientation* of 3D objects " -"starting from the initial default *\"unrotated\"* state (it's difficult to " -"calculate the 3 Euler angles for driving an object from a non-trivial " -"initial orientation to a non-trivial final orientation ---it can't be " -"calculated intuitively in general, it is a task for computers). For this " -"reason, Godot's property editor uses Euler angles (in extrinsic YXZ " -"convention; if the node has a parent node, the YXZ axes refer to the local " -"axes of the parent) for the rotation property of a Transform --this is " -"pretty much the only place Euler angles are used in Godot." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:365 -msgid "" -"So the answer to the question \"should I use Euler angles or axis-angle " -"parametrization in my game\" is: unless you're trying to *statically* orient " -"an object in a particular way starting from an *unrotated, default " -"orientation* (for which you can still use axis-angle parametrization in your " -"script, if you prefer), you shouldn't be using Euler angles. Major reasons " -"are:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:367 -msgid "" -"Jerky interpolations. You can't interpolate two orientations smoothly " -"(torque-free) in a way that is reference independent (which doesn't depend " -"on how you choose the 3 fixed rotation axes)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:368 -msgid "" -"Gimbal lock. Rotation dynamics (which includes interpolations) can get worse " -"than jerky, you can get stuck in a weird coordinate singularity (the kind " -"which doesn't exist in axis-angle parametrization) and never reach your " -"target." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:372 -msgid "A note about surface of 3-torus and sphere, and Gimbal lock" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:374 -msgid "" -"What is a 3-torus, to begin with? The surface of a donut is a 2-torus, " -"referring to the fact that the surface itself is two-dimensional (although " -"curved), which is easy to visualize. However, it's difficult to visualize a " -"torus in higher dimensions. But as it turns out, there is another way of " -"thinking about torus, which generalizes to higher dimensions." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:376 -msgid "" -"Imagine an ant walking on the surface of a donut illustrated below (image " -"borrowed from `here `_)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:381 -msgid "" -"If it keeps walking along either the red or the blue lines, it will " -"eventually come back to where it started. At any time, we can use two angles " -"to describe where the ant is: one angle (:math:`\\theta` which goes between :" -"math:`0` and :math:`2\\pi`) describing it's position along the red line, and " -"another one (:math:`\\phi`, again between :math:`0` and :math:`2\\pi`) for " -"the blue line. And note that we have periodicity: :math:`(\\theta,\\phi)` " -"and :math:`(\\theta + 2\\pi N,\\phi + 2\\pi N)` describe exactly the same " -"point on the donut for an integer :math:`N`. We have two angles, of course, " -"because we're talking about a two-dimensional surface. Now we're ready to " -"talk about :math:`n`-dimensional surfaces." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:383 -msgid "" -"If you have a set of :math:`n` \"coordinates\" (or angles) which are " -"periodic, just like :math:`\\theta` and :math:`\\phi` were (which is the " -"case for the three Euler angles), then people say those coordinates describe " -"a point on the surface of an :math:`n`-torus. (In the case that the period " -"of a \"coordinate\" is different than :math:`2\\pi`, that coordinate can be " -"scaled to make it so, such that it corresponds to an :math:`n`-torus)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:385 -msgid "" -"Now, back to our original issue. The axis of the axis-angle parametrization " -"(which is *the* natural way of parametrizing rotations, and is a one-to-one " -"covering map of SO(3); in fact, this is true for all Lie groups, not just " -"rotations in 3D) spans a sphere (every point in a ball of radius :math:`" -"\\pi` corresponds to a rotation in SO(3) where the rotation amount is mapped " -"to radius and rotation axis points is the direction from the origin; with " -"the additional caveat that if you flip the sign of the axis and angle " -"simultaneously, it maps to the same rotation), which is described using " -"spherical coordinates, whereas Euler angles span the surface of a 3-torus " -"(such that every point on the 3-torus corresponds to a rotation), which is " -"described by the three Euler angles. The problem here is, a sphere is " -"topologically different from a torus. In simple terms, this means that it's " -"impossible to deform a sphere to a torus \"smoothly\": at some point, you " -"have to punch a hole in it to make a donut from a ball (and you can never " -"\"punch a hole\" or change the topology when you stick with a " -"parametrization: if you use Euler angles, you're forever stuck walking the " -"surface of a 3-donut, and if you use axis-angle, you're forever stuck flying " -"inside the sphere)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:389 -msgid "" -"Why is this a problem at all? Because it means that a smooth walk (flight?) " -"inside the sphere doesn't always correspond to a smooth walk on the surface " -"of the 3-torus, vice versa: a 3-torus and sphere are globally different, " -"which is a fact you're bound to discover if you walk the parameter space by " -"a smoothly rotating a body using these parametrizations. Axis-angle " -"parametrization has singularities at the poles (where the azimuthal angle is " -"ill-defined) but that's fine because that's exactly how SO(3) is, after all, " -"axis-angle is how Lie groups are parametrized. Euler angle parametrization " -"also has singularities corresponding to points where two gimbals are " -"aligned, but those singularities are different from SO(3)'s poles." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:393 -msgid "" -"Suppose that you're at a nice spot, a rotation that can be parametrized by " -"both axis-angle and Euler angles uniquely. Sometimes, it can just happen " -"that if you take a wrong step, you'll fall into a \"hole\" (meaning a " -"singularity at which infinitely many parameters correspond to the same " -"rotation, like at the poles, all choices for the azimuthal angle give the " -"same rotation, or the similar situation with gimbal lock) in one " -"parametrization, while you can continue a smooth journey in the other " -"parametrization. When you fall a \"hole\" using Euler angles, it's called " -"gimbal lock, and since there may not be a corresponding \"hole\" when you " -"take the similar step in the sphere, this tells us that Euler angles is a " -"defective parametrization of SO(3)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:395 -msgid "" -"The root of the problem isn't just the fact that Euler angle parametrization " -"has singularties, just as axis-angle does which is fine on its own, but that " -"those singularities don't match with SO(3)'s singularities." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:398 -msgid "This is the mathematical description of the gimbal-lock problem." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:400 -msgid "" -"Here's an example of gimbal lock in Euler angle parametrization. Suppose " -"that one of the rotations is :math:`\\pi/2`, let's say the middle one. By " -"inserting an identity operator :math:`X(-\\pi/2) X(\\pi/2)` to the right " -"side and rearranging terms, we can show that" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:406 -msgid "" -"(see the section about active transformation below about how a rotation " -"matrix itself transforms, which also explains why and how a Z rotation turns " -"into a Y rotation when surrounded by :math:`\\pi/2` and :math:`-\\pi/2` X " -"rotations) which means we lost a degree of freedom: :math:`\\varphi_y-" -"\\varphi_z` effectively became a single parameter determining the Y rotation " -"and we completely lost the first Z rotation. You can follow similar steps to " -"show that when *any* of the YXZ Euler angles become :math:`\\pm \\pi/2`, you " -"get a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:408 -msgid "" -"This happens for :math:`\\pm \\pi/2` simply because in the YXZ convention, " -"neighboring axes are related to each other by a :math:`\\pm \\pi/2` rotation " -"around the axis given by the other neighbor. For XZX convention, the gimbal " -"lock would happen at :math:`\\varphi_z = \\pm \\pi` for example." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:412 -msgid "Summary: representation versus parametrization" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:414 -msgid "We can sum it up in a table:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:417 -msgid "Parametrization/Representation" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid "Axis-angle" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot \\boldsymbol J}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:419 -msgid ":math:`e^{\\varphi \\boldsymbol v \\cdot (i,j,k)/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid "Euler-angles" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 J_y} e^{\\varphi_2 J_x} e^{\\varphi_1 J_z}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:421 -msgid ":math:`e^{\\varphi_3 j/2} e^{\\varphi_2 i/2} e^{\\varphi_1 k/2}`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:424 -msgid "" -"where :math:`\\boldsymbol J` denotes the matrix representation of the :math:" -"`\\boldsymbol J` operators (too lazy to introduce a new symbol for that). " -"YXZ Euler angles is chosen for concreteness (as it is the default convention " -"in Godot), and can be replaced by any three axes (as long as two neighboring " -"axes aren't the same)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:426 -msgid "" -"In all cases listed in the above table, Rodrigues' formula (or it's analogue " -"for quaternions) given above can be used for practical purposes." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:428 -msgid "" -"In the context of 3D rotations, one representation isn't superior or " -"inferior to another. Whatever representation you're using, you are " -"representing exactly the same thing. A difference appears only when you " -"implement it on a computer: different representations have trade offs when " -"it comes to precision errors, CPU cycles and memory usage (for example, " -"accessing to rotation axis-angle with quaternions is trivial but requires " -"some algebra in matrix representation whereas the converse is true when " -"accessing the basis vectors, SLERP, composition of rotations and " -"orthonormalization is faster with quaternions but a conversion to matrix " -"representation, which isn't free, is always required because that's the " -"representation OpenGL uses and rotating a 3D vector is faster in matrix " -"representation since they are written in the same basis), and they may have " -"different characteristics when doing finite precision arithmetic with " -"floating point numbers. In principle, you can do everything you do with " -"quaternions using matrices, vice versa. The performance could be bad in one " -"representation, but the point is, there is nothing in their mathematics that " -"prevent you from doing that." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:430 -msgid "" -"Parametrizations, on the other hand, are vastly different. Axis-angle is the " -"\"one true\" parametrization of rotations. Euler angles, despite being a " -"defective parametrization of rotations, could be more intuitive for simple " -"(involving only 1 or 2 angles) and *static* situations like orienting a " -"body/vehicle in the editor, but should be avoided for rotational *dynamics* " -"which would eventually lead to a gimbal lock." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:434 -msgid "Interpolating rotations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:436 -msgid "" -"In games, it's common problem to interpolate between two different " -"orientation in a \"nice way\" which doesn't depend on arbitrary things like " -"how the reference frame, and which doesn't result in a \"jerky\" motion " -"(that is, a torque-free motion) such that the angular speed remains constant " -"during the interpolation. These are the properties that we seek when we say " -"\"nice\"." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:438 -msgid "" -"Formally, we'd like to interpolate between an initial rotation :math:`R_1 = " -"e^{\\lambda \\varphi_1 \\boldsymbol n_1 \\cdot \\boldsymbol J }` and a final " -"one :math:`R_2 = e^{\\varphi_2 \\boldsymbol n \\cdot \\boldsymbol J }` a " -"function of time, and what we're seeking is something that transforms one " -"into another smoothly, :math:`R(\\lambda)`, where :math:`\\lambda` is the " -"normalized time which is 0 at the beginning and 1 at the end. Clearly, we " -"must have :math:`R(\\lambda=0)=R_1` and :math:`R(\\lambda=1) = R_2`. Since " -"we also know that rotations form a group, we can relate :math:`R(\\lambda)` " -"to :math:`R_1` and :math:`R_2` using another rotation, such that we can for " -"example write" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:444 -msgid "" -"This form makes sense because for :math:`\\lambda=0`, the interpolation " -"hasn't started and :math:`R(\\lambda)` automatically becomes :math:`R_1`. " -"But why not pick a different form for the exponent as a function of :math:`" -"\\lambda` which evaluates to 0 when :math:`\\lambda=0`? That's simply " -"because we don't want to have a jerky motion, meaning :math:`\\boldsymbol " -"\\omega \\cdot \\boldsymbol J = R^T(\\lambda) \\dot R(\\lambda)`, where :" -"math:`\\boldsymbol \\omega` is the angular velocity vector, has to be a " -"constant, which can only happen if the time derivative of the exponent is " -"linear in time (in which case we obtain :math:`\\boldsymbol \\omega = " -"\\varphi \\boldsymbol n`). Or equivalently, you can simply observe that a " -"rotation around a fixed axis (fixed because otherwise if you tilt the " -"rotation axis in time, you'll again get a \"jerky motion\" due to `Euler " -"force `_) with constant angular " -"speed is :math:`e^{\\boldsymbol \\omega t \\cdot \\boldsymbol J }` where the " -"exponent is linear in time." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:447 -msgid "" -"But how do we choose :math:`\\boldsymbol n` and :math:`\\varphi`? Well, we " -"simply enforce that :math:`R(\\lambda)` has to becomes :math:`R_2` at the " -"end, when :math:`\\lambda=1`. Although this looks like a difficult problem, " -"it's actually not. We first make a rearrangement:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:453 -msgid "" -"From this expression, it becomes evident that the solution is :math:" -"`e^{\\varphi \\boldsymbol n \\cdot \\boldsymbol J } = R_2 R_1^T`." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:455 -msgid "We can also do the same thing in SU(2) and obtain:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:461 -msgid "or isomorphically, in terms of quaternions:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:467 -msgid "" -"For any Lie group, including SO(3) and SU(2), this \"nice\" interpolation is " -"called SLERP." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:469 -msgid "" -"Note that at no step we made any reference to axes of some fixed reference " -"frame (as it is in the case of Euler angle parametrization, which are " -"defined with respect to certain \"special\" 3 axes), everything we did is " -"independent of the reference frame. Also note that this scheme can work for " -"any Lie group, and is independent of the representation used (matrix, " -"quaternion, ...)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:471 -msgid "" -"After some tedious algebra (which involves using :math:`\\text{tr}(\\sigma_i " -"\\sigma_j) = 2 \\delta_{ij}`), this result can be simplified to" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:477 -msgid "" -"when :math:`q_1 \\neq \\pm q_2`, where we introduced :math:`\\cos\\Omega " -"\\equiv \\cos\\frac{\\varphi_1}{2}\\cos\\frac{\\varphi_2}{2} + \\sin" -"\\frac{\\varphi_1}{2}\\sin\\frac{\\varphi_2}{2} \\boldsymbol n_1 \\cdot " -"\\boldsymbol n_2` (or equivalently, in terms of an artificial vector which " -"contains the coefficients of the quaternions, as we discussed above, :math:`" -"\\boldsymbol q_1 \\cdot \\boldsymbol q_2`). This result has a simple " -"geometric interpretation when a (unit) quaternion is taken to be a point on " -"the 3-sphere and when one introduces an inner product of the 4D Euclidean " -"space, but we'll skip that because it's a bit off topic in our treatment. " -"We'll however note that this is where the name *Spherical* Linear " -"intERpolation comes from, which refers to the 4D sphere." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:482 -msgid "Reference frames: global, parent-local, object-local" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:484 -msgid "" -"A reference frame essentially how and where how place the origin and axes of " -"your coordinate system. In Godot, there are three different reference " -"frames. The first is the global reference frame. It exist as the \"anchor\" " -"frame, where all other frames can be defined with respect to. The other " -"types of reference frames appear when you have objects which have children " -"objects. Here's an example which illustrates these frames." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:486 -msgid "" -"Consider a ship in the ocean. You can imagine, however that there's a " -"coordinate system painted on the ground somewhere in the ship. This " -"coordinate system moves and rotates with the ship, so it's called ship's " -"local frame. Furthermore, we can attach a reference frame to passengers on " -"the ship (for example, let's say, for each passenger, their left is their :" -"math:`x`-axis and their forward is their :math:`z` axis, and their origin is " -"where they stand)." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:488 -msgid "" -"The global coordinate system corresponds to a coordinate system world " -"painted somewhere on the ground in the world (let's say we live in a flat " -"world for simplicity). Then every object, including the ship and the " -"passengers have their own reference frames, they're called object-local " -"frames. But notice that for passengers, the most natural frame would be " -"where they are located (and how they're oriented) relative to the ship. " -"After all, when someone asks \"Where's Joe?\", you'd reply with something " -"like \"I saw him in the front deck\" rather than trying to look up GPS " -"coordinates (global frame) or saying something like \"7 meters to my five " -"o'clock\" (passenger/object-local). The ship is referred to as the parent-" -"local frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:490 -msgid "" -"In Godot, Basis matrices refer to the parent-local frame. If the object is " -"top level, then it's Basis is written in the global frame." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:495 -msgid "Active and passive transformations" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:497 -msgid "" -"While operators (such as :math:`e^{\\varphi \\boldsymbol n \\cdot " -"\\boldsymbol J}` ) and vectors :math:`\\boldsymbol v` are \"out there\" and " -"are independent of the reference frame, their coordinates aren't. For " -"example, a vector can be aligned with the :math:`x`-axis in some frame " -"whereas in can be aligned with :math:`y`-axis in another, if you choose to " -"draw your coordinate system differently. But the vector doesn't know about " -"your arbitrary choice of how and where you draw your coordinate system. When " -"we have multiple reference frames, it's important how the coordinates would " -"transform between them." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:499 -msgid "" -"For example, if you know that the coordinates of a vector :math:`" -"\\boldsymbol v` are given as :math:`v_x, v_y, v_z` in some reference frame, " -"you can obtain the coordinates in a different frame which is rotated which " -"respect to the first one around some :math:`\\boldsymbol n` axis by :math:`-" -"\\varphi` as" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:505 -msgid "" -"where primed coordinates correspond to coordinates in the rotated *frame*. " -"You can also transform the matrix representations of operators. For " -"example, :math:`M_{ij} = \\boldsymbol e_i \\cdot M \\boldsymbol e_j` but " -"what is the rotation matrix if we used the basis vectors of a different " -"frame :math:`\\{\\boldsymbol e_i'\\}`? To obtain the matrix representation " -"of :math:`M` in the new frame, you can do" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:512 -msgid "These are called passive transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:514 -msgid "" -"Now let's consider actually moving those objects (we consider only one " -"reference frame and it's fixed). We rotate a vector around some :math:`" -"\\boldsymbol n` axis by :math:`\\varphi`" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:520 -msgid "" -"where primed coordinates are the coordinates of the rotated *vector*, in the " -"same reference frame. Similarly, for matrices" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:527 -msgid "These are called active transformations." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:530 -msgid "" -"Note how things fit nicely, for example, when you consider how a rotated " -"vector :math:`R_0 \\boldsymbol v_0` transforms:" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:536 -msgid "" -"The left hand side is rotation of the vector :math:`(R_0 \\boldsymbol v_0)` " -"and the right hand side is the rotation of the vector :math:`v_0` and the " -"matrix :math:`R_0` that acts on it, which of course agree." -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:539 -msgid "" -"The rotation operator itself rotates in a expected way (you can use " -"Rodrigues' formula along with the equation above, if you prefer):" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:545 -msgid "" -"For example, if we have a rotation around the :math:`z`-axis by :math:`" -"\\varphi_0 = \\varphi_z` and we would like to rotate it around the :math:`x`-" -"axis by :math:`\\varphi = \\pi/2`, we'd have" -msgstr "" - -#: ../../docs/tutorials/math/rotations.rst:551 -msgid "" -"that is, the original rotation axis :math:`\\boldsymbol n_0 = \\boldsymbol " -"e_z` gets rotated around the :math:`x`-axis by :math:`\\varphi = \\pi/2` and " -"becomes a rotation around the :math:`y`-axis by :math:`-\\varphi_z`." -msgstr "" - #: ../../docs/tutorials/math/matrices_and_transforms.rst:4 msgid "Matrices and transforms" msgstr "" @@ -40254,7 +39005,7 @@ msgid "Or alternatively, set it via function:" msgstr "" #: ../../docs/tutorials/gui/custom_gui_controls.rst:112 -#: ../../docs/tutorials/viewports/viewports.rst:28 +#: ../../docs/tutorials/viewports/viewports.rst:38 msgid "Input" msgstr "" @@ -40642,226 +39393,345 @@ msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:9 msgid "" -"Godot has a small but useful feature called viewports. Viewports are, as the " -"name implies, rectangles where the world is drawn. They have three main " -"uses, but can flexibly adapted to a lot more. All this is done via the :ref:" -"`Viewport ` node." +"Think of :ref:`Viewports ` as a screen that the game is " +"projected onto. In order to see the game we need to have a surface to draw " +"it on, this surface is the Root :ref:`Viewport `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:16 -msgid "The main uses in question are:" +msgid "" +":ref:`Viewports ` can also be added to the scene so that " +"there are multiple surfaces to draw on. When we are drawing to a :ref:" +"`Viewport ` that is not the Root we call it a render target. " +"We can access the contents of a render target by accessing its " +"corresponding :ref:`texture `. By using a :ref:" +"`Viewport ` as a render target we can either render multiple " +"scenes simultaneously or we can render to a :ref:`texture " +"` which is applied to an object in the scene, for " +"example a dynamic skybox." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:18 +#: ../../docs/tutorials/viewports/viewports.rst:25 msgid "" -"**Scene Root**: The root of the active scene is always a Viewport. This is " -"what displays the scenes created by the user. (You should know this by " -"having read previous tutorials!)" +":ref:`Viewports ` have a variety of use cases including:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:21 -msgid "" -"**Sub-Viewports**: These can be created when a Viewport is a child of a :ref:" -"`Control `." +#: ../../docs/tutorials/viewports/viewports.rst:27 +msgid "Rendering 3d objects within a 2d game" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:23 -msgid "" -"**Render Targets**: Viewports can be set to \"RenderTarget\" mode. This " -"means that the viewport is not directly visible, but its contents can be " -"accessed via a :ref:`Texture `." +#: ../../docs/tutorials/viewports/viewports.rst:28 +msgid "Rendering 2d elements in a 3d game" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:29 +msgid "Rendering dynamic textures" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:30 +msgid "Generating procedural textures at runtime" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:31 +msgid "Rendering multiple cameras in the same scene" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:33 msgid "" -"Viewports are also responsible of delivering properly adjusted and scaled " -"input events to all its children nodes. Both the root viewport and sub-" -"viewports do this automatically, but render targets do not. Because of this, " -"the user must do it manually via the :ref:`Viewport.input() " -"` function if needed." +"What all these use cases have in common is that you are given the ability to " +"draw objects to a texture as if it were another screen and then you can " +"choose what to do with the resulting texture." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:37 -msgid "Listener" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:39 +#: ../../docs/tutorials/viewports/viewports.rst:40 msgid "" -"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " -"in another tutorial (one day..). For this type of sound to be audible, the " -"viewport needs to be enabled as a listener (for 2D or 3D). If you are using " -"a custom viewport to display your world, don't forget to enable this!" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:46 -msgid "Cameras (2D & 3D)" +":ref:`Viewports ` are also responsible for delivering " +"properly adjusted and scaled input events to all their children nodes. " +"Typically input is received by the nearest :ref:`Viewport ` " +"in the tree, but you can set :ref:`Viewports ` to not " +"recieve input by checking 'Disable Input' to 'on', this will allow the next " +"nearest :ref:`Viewport ` in the tree to capture the input." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:48 msgid "" -"When using a 2D or 3D :ref:`Camera ` / :ref:`Camera2D " -"`, cameras will always display on the closest parent " -"viewport (going towards the root). For example, in the following hierarchy:" +"For more information on how Godot handles input please read the :ref:`Input " +"Event Tutorial`." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:51 +msgid "Listener" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:53 -#: ../../docs/tutorials/viewports/viewports.rst:61 -#: ../../docs/tutorials/viewports/viewports.rst:159 -msgid "Viewport" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:55 -#: ../../docs/tutorials/viewports/viewports.rst:59 -msgid "Camera" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:57 -msgid "Camera will display on the parent viewport, but in the following one:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:63 msgid "" -"It will not (or may display in the root viewport if this is a subscene)." +"Godot supports 3D sound (in both 2D and 3D nodes), more on this can be found " +"in the :ref:`Audio Streams Tutorial`. For this type of " +"sound to be audible, the :ref:`Viewport ` needs to be " +"enabled as a listener (for 2D or 3D). If you are using a custom :ref:" +"`Viewport ` to display your :ref:`World `, " +"don't forget to enable this!" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:65 +#: ../../docs/tutorials/viewports/viewports.rst:60 +msgid "Cameras (2D & 3D)" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:62 msgid "" -"There can be only one active camera per viewport, so if there is more than " -"one, make sure that the desired one has the \"current\" property set, or " -"make it the current camera by calling:" +"When using a :ref:`Camera ` / :ref:`Camera2D " +"`, cameras will always display on the closest parent :ref:" +"`Viewport ` (going towards the root). For example, in the " +"following hierarchy:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:74 +#: ../../docs/tutorials/viewports/viewports.rst:69 +msgid "" +"CameraA will display on the Root :ref:`Viewport ` and it " +"will draw MeshA. CameraB will be captured by the :ref:`Viewport " +"` Node along with MeshB. Even though MeshB is in the scene " +"heirarchy, it will still not be drawn to the Root :ref:`Viewport " +"`. Similarly MeshA will not be visible from the :ref:" +"`Viewport ` node becuase :ref:`Viewport ` " +"nodes only capture nodes below them in the heirarchy." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:75 +msgid "" +"There can only be one active camera per :ref:`Viewport `, so " +"if there is more than one, make sure that the desired one has the \"current" +"\" property set, or make it the current camera by calling:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:84 msgid "Scale & stretching" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:76 +#: ../../docs/tutorials/viewports/viewports.rst:86 msgid "" -"Viewports have a \"rect\" property. X and Y are often not used (only the " -"root viewport uses them), while WIDTH AND HEIGHT represent the size of the " -"viewport in pixels. For Sub-Viewports, these values are overridden by the " -"ones from the parent control, but for render targets this sets their " -"resolution." +":ref:`Viewports ` have a \"size\" property which represents " +"the size of the :ref:`Viewport ` in pixels. For :ref:" +"`Viewports ` which are children of :ref:`ViewportContainers " +"`, these values are overridden, but for all others " +"this sets their resolution." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:82 +#: ../../docs/tutorials/viewports/viewports.rst:90 msgid "" -"It is also possible to scale the 2D content and make it believe the viewport " -"resolution is other than the one specified in the rect, by calling:" +"It is also possible to scale the 2D content and make the :ref:`Viewport " +"` resolution different than the one specified in size, by " +"calling:" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:91 +#: ../../docs/tutorials/viewports/viewports.rst:98 msgid "" -"The root viewport uses this for the stretch options in the project settings." +"The root :ref:`Viewport ` uses this for the stretch options " +"in the project settings. For more information on scaling and stretching " +"visit the :ref:`Multiple Resolutions Tutorial `" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:95 +#: ../../docs/tutorials/viewports/viewports.rst:102 msgid "Worlds" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:97 +#: ../../docs/tutorials/viewports/viewports.rst:104 msgid "" -"For 3D, a Viewport will contain a :ref:`World `. This is " -"basically the universe that links physics and rendering together. Spatial-" -"base nodes will register using the World of the closest viewport. By " -"default, newly created viewports do not contain a World but use the same as " -"a parent viewport (root viewport does contain one though, which is the one " -"objects are rendered to by default). A world can be set in a viewport using " -"the \"world\" property, and that will separate all children nodes of that " -"viewport from interacting with the parent viewport world. This is especially " -"useful in scenarios where, for example, you might want to show a separate " -"character in 3D imposed over the game (like in Starcraft)." +"For 3D, a :ref:`Viewport ` will contain a :ref:`World " +"`. This is basically the universe that links physics and " +"rendering together. Spatial-base nodes will register using the :ref:`World " +"` of the closest :ref:`Viewport `. By default, " +"newly created :ref:`Viewports ` do not contain a :ref:`World " +"` but use the same as their parent :ref:`Viewport " +"` (root :ref:`Viewport ` always contains a :" +"ref:`World `, which is the one objects are rendered to by " +"default). A :ref:`World ` can be set in a :ref:`Viewport " +"` using the \"world\" property, and that will separate all " +"children nodes of that :ref:`Viewport ` from interacting " +"with the parent :ref:`Viewport's ` :ref:`World " +"`. This is especially useful in scenarios where, for example, " +"you might want to show a separate character in 3D imposed over the game " +"(like in Starcraft)." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:109 +#: ../../docs/tutorials/viewports/viewports.rst:116 msgid "" -"As a helper for situations where you want to create viewports that display " -"single objects and don't want to create a world, viewport has the option to " -"use its own World. This is useful when you want to instance 3D characters or " -"objects in the 2D world." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:114 -msgid "" -"For 2D, each Viewport always contains its own :ref:`World2D " -"`. This suffices in most cases, but in case sharing them may " -"be desired, it is possible to do so by calling the viewport API manually." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:119 -msgid "Capture" +"As a helper for situations where you want to create :ref:`Viewports " +"` that display single objects and don't want to create a :" +"ref:`World `, :ref:`Viewport ` has the option " +"to use its own :ref:`World `. This is useful when you want to " +"instance 3D characters or objects in a 2D :ref:`World `." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:121 msgid "" -"It is possible to query a capture of the viewport contents. For the root " -"viewport this is effectively a screen capture. This is done with the " -"following API:" +"For 2D, each :ref:`Viewport ` always contains its own :ref:" +"`World2D `. This suffices in most cases, but in case sharing " +"them may be desired, it is possible to do so by setting the :ref:`Viewport's " +"` :ref:`World2D ` manually." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:137 +#: ../../docs/tutorials/viewports/viewports.rst:125 msgid "" -"But if you use this in _ready() or from the first frame of the viewport's " -"initialization you will get an empty texture cause there is nothing to get " -"as texture. You can deal with it using (for example):" +"For an example of how this works see the demo projects `3D in 2D `_ " +"and `2D in 3D `_ respectively." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:148 +#: ../../docs/tutorials/viewports/viewports.rst:128 +msgid "Capture" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:130 +msgid "" +"It is possible to query a capture of the :ref:`Viewport ` " +"contents. For the root :ref:`Viewport ` this is effectively " +"a screen capture. This is done with the following code:" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:147 +msgid "" +"But if you use this in _ready() or from the first frame of the :ref:" +"`Viewport's ` initialization you will get an empty texture " +"cause there is nothing to get as texture. You can deal with it using (for " +"example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:158 msgid "" "If the returned image is empty, capture still didn't happen, wait a little " -"more, as this API is asynchronous." +"more, as Godot's rendering API is asynchronous. For a working example of " +"this check out the `Screen Capture example `_ in the demo " +"projects" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:152 -msgid "Sub-viewport" +#: ../../docs/tutorials/viewports/viewports.rst:163 +msgid "Viewport Container" msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:154 +#: ../../docs/tutorials/viewports/viewports.rst:165 msgid "" -"If the viewport is a child of a :ref:`ViewportContainer " -"`, it will become active and display anything it " -"has inside. The layout is something like this:" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:157 -msgid "ViewportContainer" -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:161 -msgid "" -"The viewport will cover the area of its parent control completely, if " -"stretch is set to true in Viewport Container. But you will have to setup the " -"Viewport Size to get the the appropriate part of the Viewport. And Viewport " -"Container can not be smaller than the size of the Viewport." -msgstr "" - -#: ../../docs/tutorials/viewports/viewports.rst:168 -msgid "Render target" +"If the :ref:`Viewport ` is a child of a :ref:" +"`ViewportContainer `, it will become active and " +"display anything it has inside. The layout looks like this:" msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:170 msgid "" -"To set as a render target, toggle the \"render target\" property of the " -"viewport to enabled. Note that whatever is inside will not be visible in the " -"scene editor. To display the contents, the method remains the same. This can " -"be requested via code using (for example):" +"The :ref:`Viewport ` will cover the area of its parent :ref:" +"`ViewportContainer ` completely if stretch is set " +"to true in :ref:`ViewportContainer `. Note: The " +"size of the :ref:`ViewportContainer ` cannot be " +"smaller than the size of the :ref:`Viewport `." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:181 +#: ../../docs/tutorials/viewports/viewports.rst:177 msgid "" -"By default, re-rendering of the render target happens when the render target " -"texture has been drawn in a frame. If visible, it will be rendered, " -"otherwise it will not. This behavior can be changed to manual rendering " -"(once), or always render, no matter if visible or not." +"Due to the fact that the :ref:`Viewport ` is an entryway " +"into another rendering surface, it exposes a few rendering properties that " +"can be different from the project settings. The first is MSAA, you can " +"choose to use a different level of MSAA for each :ref:`Viewport " +"`, the default behavior is DISABLED. You can also set the :" +"ref:`Viewport ` to use HDR, HDR is very useful for when you " +"want to store values in the texture that are outside the range 0.0 - 1.0." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:183 +msgid "" +"If you know how the :ref:`Viewport ` is going to be used, " +"you can set its Usage to either 3D or 2D. Godot will then restrict how the :" +"ref:`Viewport ` is drawn to in accordance with your choice, " +"default is 3D." msgstr "" #: ../../docs/tutorials/viewports/viewports.rst:186 -msgid "``TODO: Review the doc, change outdated and add more images.``" +msgid "" +"Godot also provides a way of customizing how everything is drawn inside :ref:" +"`Viewports ` using “Debug Draw”. Debug Draw allows you to " +"specify one of four options for how the :ref:`Viewport ` " +"will display things drawn inside it. Debug Draw is disabled by default." msgstr "" -#: ../../docs/tutorials/viewports/viewports.rst:188 +#: ../../docs/tutorials/viewports/viewports.rst:192 +msgid "*A scene drawn with Debug Draw disabled*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:194 msgid "" -"Make sure to check the viewport demos! Viewport folder in the demos archive " +"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded " +"draws the scene without using lighting information so all the objects appear " +"flatly colored the color of their albedo." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:200 +msgid "*The same scene with Debug Draw set to Unshaded*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:202 +msgid "" +"Overdraw draws the meshes semi-transparent with an additive blend so you can " +"see how the meshes overlap." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:206 +msgid "*The same scene with Debug Draw set to Overdraw*" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:208 +msgid "" +"Lastly, Wireframe draws the scene using only the edges of triangles in the " +"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and " +"currently just renders the scene normally." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:212 +msgid "Render target" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:214 +msgid "" +"When rendering to a :ref:`Viewport ` whatever is inside will " +"not be visible in the scene editor. To display the contents, you have to " +"draw the :ref:`Viewport's ` :ref:`ViewportTexture " +"` somewhere. This can be requested via code using " +"(for example):" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:224 +msgid "" +"Or it can be assigned in the editor by selecting \"New ViewportTexture\"" +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:228 +msgid "" +"and then selecting the :ref:`Viewport ` you want to use." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:232 +msgid "" +"Every frame the :ref:`Viewport `'s texture is cleared away " +"with the default clear color (or a transparent color if Transparent BG is " +"set to true). This can be changed by setting Clear Mode to Never or Next " +"Frame. As the name implies, Never means the texture will never be cleared " +"while next frame will clear the texture on the next frame and then set " +"itself to Never." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:237 +msgid "" +"By default, re-rendering of the :ref:`Viewport ` happens " +"when the :ref:`Viewport `'s :ref:`ViewportTexture " +"` has been drawn in a frame. If visible, it will be " +"rendered, otherwise it will not. This behavior can be changed to manual " +"rendering (once), or always render, no matter if visible or not. This " +"flexibility allows users to render an image once and then use the texture " +"without incurring the cost of rendering every frame." +msgstr "" + +#: ../../docs/tutorials/viewports/viewports.rst:245 +msgid "" +"Make sure to check the Viewport demos! Viewport folder in the demos archive " "available to download, or https://github.com/godotengine/godot-demo-projects/" "tree/master/viewport" msgstr "" @@ -47307,9 +46177,9 @@ msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212 msgid "" -"Before we jump back into Godot we need to create two more files. Both can " -"now be created through the interface in Godot but I find it easier to just " -"create them directly." +"Before we jump back into Godot we need to create two more files in ``demo/" +"bin/`` . Both can now be created through the interface in Godot but I find " +"it easier to just create them directly." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214 @@ -47363,7 +46233,7 @@ msgid "" "easier in (re)using your native_script. The important bits here are that " "we're pointing to our gdnlib file so Godot knows which dynamic library " "contains our native_script, and the ``class_name`` which identifies the " -"natice_script in our plugin we want to use." +"native_script in our plugin we want to use." msgstr "" #: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264 @@ -51959,6 +50829,10 @@ msgstr "" msgid "Godot provides also a set of common containers:" msgstr "" +#: ../../docs/development/cpp/core_types.rst:143 +msgid "Vector" +msgstr "" + #: ../../docs/development/cpp/core_types.rst:144 msgid "List" msgstr ""